-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SciMLBook
Parallel Computing and Scientific Machine Learning (SciML): Methods and Applications (MIT 18.337J/6.338J)
-
-
Great writeup. Minor comment about the portion of the post mentioning Conda being glacially slow: Mamba [1] is a much better drop-in replacement written in C++. Not only is it significantly faster, but error messages are much more sane and helpful.
That being said, I do agree that Pkg.jl is much more sleek and modern than Conda/Mamba.
[1]: https://github.com/mamba-org/mamba
The error messages you mentioned in here have been completely overhauled. In fact, most things in SciML are now caught and throw very high level error messages. We also revamped the whole documentation and added docstrings everywhere. See https://sciml.ai/news/2022/10/08/error_messages/ . We're also in the middle of rolling out a new documentation (https://docs.sciml.ai/Overview/stable/) that has a lot more of a split between tutorials and references. It's not complete, but the core push of this should be completed in about 2 weeks. As for loading times, we've transformed those as documented in https://sciml.ai/news/2022/09/21/compile_time/ (taking a core case from 30 seconds to 0.1 seconds), and Julia v1.9 is releasing a feature where package precompilation can store LLVM-compiled binaries.
So I think most of the blog post has already been addressed?
The one thing we haven't done is improved type printing. I am with you on that one, and actually opened a Base Julia issue about it way before your blog post: https://github.com/JuliaLang/julia/issues/36517 . It requires a Base Julia fix though, so that's a bit out of my hands. Also, I think it would be good for Base Julia to do a bit of the error message interpreting that SciML has done, specifically for broadcast (https://github.com/JuliaLang/julia/issues/45086). So there are some more improvements to be done, but I don't think the blog post is up-to-date given the overhauls that were done in the summer of 2022 (thanks to your feedback).
It would be nice to hear updated thoughts when you have a chance to try all of these improvements (especially when v1.9 comes out with the cached binaries)!
I'm hoping the new SciML docs can become a good enough source for beginners looking to do scientific computing (https://docs.sciml.ai/Overview/stable/). It's not there yet, we literally started redirecting links to the new docs on Monday so that's how new it is, it's already moving in the direction of having a lot of materials for new users (in scientific computing specifically, this is not and will not be a general Julia resource) before ever hitting deeper features.
Though if someone wants to dive deep into the language, I'd plug my own SciML course notes: https://book.sciml.ai/, which again is not for general usage but scientific computing but does show a lot about good programming styles (see https://book.sciml.ai/notes/02-Optimizing_Serial_Code/).
Software has bugs. That's the way it is. You may think that Julia (but I suppose this is mostly about the ecosystem of packages around Julia) has too many bugs. Then you can use something else. Like Python. If you move from Julia to Python, you may want to use Numpy? Pretty cool project. It currently has 1,9k issues on Github and if you filter by bugs, it has 599 such labeled issues. How many of those are issues like in the post? I don't know. The same applies to Scipy. For example, the gaussian hypergeometric function returns wrong results for some input values https://github.com/scipy/scipy/issues/3479. This issue was filed in 2014. You can find similar old issues in Julia packages. That's how these things go. Luckily, many of the issues listed in the blog post are fixed.
If you think that picking any language and any library combination with a semi-high requirement for the number of features you want to be already implemented will be able to fulfill the "this has to be completely correct or I won't use it for my research"-requirement you will have a hard time.
The last part of the post seems to be about OffSetArrays.jl. Many people who have implemented libraries and who care about composability and generic input also agree that the Base AbstractArray interface is not perfect or complete and sometimes the issue is that the interface that does exist is not followed well enough for composability to work. A more complete, agreed upon, and generally adhered to interface for an "AbstractArray" would be nice and has been+is being worked on and discussed by many people in the community.
> if you choose immutable structs, your interface for users is EXTREMELY annoying. For example, if they want to update `x` from `1` to be `2`
That's the whole point of immutability that you can't "just update". I fail to see how obscure magical updates on immutable (?) structs like [1] or [2] are beneficial.
Note that there is zero explanation on the front page of what actually happens under the hood. One example of why I don't have much trust in JuliaLand.
[1] https://github.com/JuliaObjects/Accessors.jl