CoherentNoise.jl
PropCheck.jl
CoherentNoise.jl | PropCheck.jl | |
---|---|---|
1 | 1 | |
64 | 79 | |
- | - | |
3.5 | 8.0 | |
about 1 month ago | about 2 months ago | |
Julia | Julia | |
MIT License | 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.
CoherentNoise.jl
PropCheck.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?
Mousetrap.jl - Finally, a GUI Engine made for Julia
DMARCParser.jl - 📦 Easily parse DMARC XML files into a more human-readable format with this high-performance Julia package.
Chain.jl - A Julia package for piping a value through a series of transformation expressions using a more convenient syntax than Julia's native piping functionality.
LibPQ.jl - A Julia wrapper for libpq
NumericalAlgorithms.jl - [DEPRECATED] Statistics & Numerical algorithms implemented in Julia.
RequiredInterfaces.jl - A small package for providing the minimal required method surface of a Julia API
cl-lsp - An implementation of the Language Server Protocol for Common Lisp
julia - The Julia Programming Language
slimv - Official mirror of Slimv versions released on vim.org
InterfaceSpecs.jl - Playground for formal specifications of interfaces in Julia