Jive.jl
RequiredInterfaces.jl
Jive.jl | RequiredInterfaces.jl | |
---|---|---|
1 | 1 | |
42 | 31 | |
- | - | |
5.7 | 6.8 | |
2 months ago | 5 days ago | |
Julia | Julia | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Jive.jl
-
How do you write Julia code?
Perhaps look into https://github.com/wookay/Jive.jl in combination with Revise.jl. Once set up, edited files get reloaded (reinterpreted) automatically, and your test reruns with the just reloaded code, all in the same interactive session. Sometimes I don't have actual code in the test file, but just use this setup to have my REPL updating after every code change.
RequiredInterfaces.jl
-
Julia as a unifying end-to-end workflow language on the Frontier exascale system
There is no rebuttal because nothing much has really changed culture wise. Sure, the various @inbounds issues and concrete bugs that are mentioned in Yuris post have mostly been addressed, but the larger point (that is, "what can I actually expect/get guaranteed when calling a given function?") definitely hasn't been, at least not culturally. Documentation of pre- and postconditions are still lackluster, PRs trying to establish that for functions in Base stall for unclear reasons/don't get followups and when you try to talk about that on Slack retorts boil down to "we're tired of hearing you complain about this" instead of trying to find a systemic solution to that problem. Until that changes, I have large doubts about Yuris post losing relevance.
My own efforts (shameless plug, https://github.com/Seelengrab/PropCheck.jl for property based testing inspired by Hedgehog and https://github.com/Seelengrab/RequiredInterfaces.jl for somewhat formalizing "what methods are needed to subtype an abstract type") are unused in the wider community as far as I can tell, in spite of people speaking highly of them when coming across them. I also don't think Kenos InterfaceSpecs.jl is the way forward either - I think there's quite a lot of design space left in the typesystem the language could do without reaching for z3 and other SAT/SMT solvers. I personally attribute the lack of progress on that front to the lack of coherent direction of the project at large (and specifically not to the failings of individuals - folks are always very busy with their lives outside of Julia development/other priorities). In spite of the fact that making this single area better could be a big boon with more traditional software engineers, which are very underrepresented in the community.
What are some alternatives?
DataFrames.jl - In-memory tabular data in Julia
Tables.jl - An interface for tables in Julia
julia - The Julia Programming Language
InterfaceSpecs.jl - Playground for formal specifications of interfaces in Julia
DifferentialEquations.jl - Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.
SciMLStyle - A style guide for stylish Julia developers
Pluto.jl - 🎈 Simple reactive notebooks for Julia
PropCheck.jl - A package for simple property based testing in julia.
PlutoTest.jl - ✔️ Visual, reactive testing library for Julia. Time machine included.
JuMP.jl - Modeling language for Mathematical Optimization (linear, mixed-integer, conic, semidefinite, nonlinear)
Makie.jl - Interactive data visualizations and plotting in Julia