So in other Julia geometry-related projects that may be true, but for this particular corner of the ecosystem the main author (Júlio Hoffimann) has actually implemented much of the underlying geometry and other code from scratch (to the best of my understanding) in pure Julia in a whole set of packages, including e.g.
For this crowd, "machine learning" should really be read as parallel Bayesian inversion via MCMC (Metropolis modified with a form of "parallel tempering"), but that was a bit much to explain to a popular audience.
The underlying paper is https://doi.org/10.1126/science.adh3875:
Cox, Alexander A., and C. Brenhin Keller. "A Bayesian inversion for emissions and export productivity across the end-Cretaceous boundary." Science 381.6665 (2023): 1446-1451.
That paper is more focused on the general concepts than the implementation, but FWIW the new code is in Julia and in the supp mat, and calls an existing C program called LOSCAR for the forward modelling.
I suspect there's a bit of an Eternal September effect going on as a wider audience ends up here (possibly fleeing the continuing "enshittification" of most all for-profit online fora)
The most IDE-ish experience is probably currently the vscode plugin. I haven’t used pycharm specifically for comparison, but I suspect “probably not” as compared to a polished paid IDE in general. There’s progress being made though.
> While the details of CCS provisioning vary in the different versions of the GPL agreements, the general principle is that CCS need to be provided either (a) along with the binary distributions to those who receive, or (b) to those who request pursuant to a written offer for source.
Since the written offer is apparently mandatory [1], does this mean that a potential way forward (if Red Hat intends to not break the GPL) is for Rocky and Alma to make regular written requests for source?
> If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
> The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
I've seen this criticism that it's "difficult to reason about which method will actually be called because of the type system" once before, but it absolutely flummoxes me... I have literally never been confused about which method is going to be called by my code, and I'm not even a proper computer scientist (just a regular scientist scientist).
Maybe this is just an issue of not having years of OO habits influencing the way I reason about dispatch in Julia?? Honestly not sure.
It has good power/weight ratio in theory, esp. if you're burning it (c.f. space shuttle), but hard to store or transport it both densely and safely in a practical way -- i.e., unless you're comfortable dragging around cryogenic lH2 in your sports car
Seasonal storage is an interesting idea. Rare grid outages seems pretty easy with batteries if the South Australia example is anything to go by though, and for medium-term storage there's also pumped hydro -- not sure where that compares in cost?
I'll go one further: Hydrogen does nothing. It's a bad battery.
After following this for more than a decade (starting with a bit of undergrad research on possible alternative fuel cell electrode materials -- albeit not a field that I'm in any way involved with any more), it just feels like there's been very little progress on fuel cells, or on storage and transport. Meanwhile, progress on Li-based batteries has been slow but steady. It's not really clear to me what advantages H has over Li as an electron donor, at this point.
It seems like you have some emotional baggage involved here.
I use Julia every day (for scientific computing). I have never worked with or for the Julia Computing folks, but don't agree with your characterization of them. I like Fortran too, but personally I would rather use Julia if I have the choice.