cbkeller

It looks like you very dramatically missed the point

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.

https://github.com/JuliaGeometry/Meshes.jl https://github.com/JuliaGeometry/Rotations.jl https://github.com/JuliaEarth/GeoStatsBase.jl https://github.com/JuliaEarth/PointPatterns.jl

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)

Femptolisp, a "Scheme dialect"

That's how it works in any language on a supercomputer. MPI is pretty much the only game in town for inter-node communication.

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?

[1] https://www.gnu.org/licenses/gpl-faq.html, specifically

> 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.

This is pretty clearly against the spirit, albeit probably not the letter, of the GPL. Sad to see.

The author links this in the fourth paragraph; their argument is that while compute is not a viable moat, training data may be.

Yes, I think so (and many already have)

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.

I think this is the best answer, as someone who's been using the language for most of my work for a few years (but not in ML).

Flux.jl is probably the highest-profile relevant effort, but it's been (AFAIU) pretty much entirely volunteer-developed for the past 2+ years.

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.

There's https://github.com/atom-community/atom, hoping that or similar will gain traction

I'm teaching an intro programming course (discipline-specific, for Earth sciences) in Julia at Dartmouth. So far so good I think -- but definitely on the sciences side of things.

Latency / "ttfx" for all sorts of things has also dropped dramatically over the past ~year, and will get another big boost with the native code caching PR

A correlation between mass extinctions and certain volcanic episodes known as "large igneous provinces" has been emerging over the last decade or two; this paper quantifies that correlation and suggests that there may have been an extinction at the end of the Cretaceous even without the asteroid impact.

All the computational work (and plotting) in here was done with Julia, including the parallel calculations with MPI.jl and VectorizedRNG.jl

Same day as RStudio changes to Posit?

I actually donate a nominal amount via github sponsors just to help support hosting costs since I find the utility useful -- specifically in my case for allowing people using my Binder notebooks to get their data out of the container without having to have a server of their own.

They ended the service, but you can host your own server -- which is what the developer of this package has done

I think some people may expect it to be something that it's not. I'm probably a broken clock on this point but it's really a fundamentally different programming paradigm (dispatch-oriented) than most anything else, and organizing your code in a way that expects and works well with that paradigm (and what that means for how code is compiled) is, in my opinion, critical. If that works well for your problems or the way you like to think about things then great, if not then you may come away quite frustrated.

Try to fight against dispatch and squeeze Julia into OO or functional or etc. paradigms and you're Gonna Have a Bad Time, in my opinion.

I considered making one but didn't really feel it was worth it; in fact, there's a bit of a catch-22 in that Julia folks seem to have accumulated a reputation of "not being able to take criticism", so I think most folks in the community just decided to take it this time. That said, if there's popular demand for a "rebuttal" of sorts I would be happy to come up with one after I get a few more things off my desk (among I'm sure many others who may be more qualified).

I think it's safe to say that Julia has a notable ability to polarize people -- you tend to either love it or hate it. Personally, I can hardly even imagine using anything else at this point.

While I think I can see where you're coming from, I will say as a personal anecdote that at this point I do feel that I can intuitively reason about the data at play quite easily, and no longer ever find myself running into any confusion about which method will be called (I don't think I've even had to check my intuition on this point with `@which` in over a year) -- but it did take me about two solid years of using Julia for a serious part of my time to get here.

It is, in my view, a fundamentally different programming paradigm that most of us have no previous built-up intuition for (unless perhaps you have spent lot of time with languages like Dylan or perhaps CLOS). But it is something you can learn and develop intuition for like anything else.

For those still learning, I may also mention `@edit`, which will not just show you the method, but take you directly to the source code of the method being called -- which is something that remains quite useful even when your intuition is fully-developed.

Ah yeah, `llvmcall` is also part of the secret to the performance of LoopVectorization.jl / VectorizationBase.jl AFAIU.

Conveniently, it's also pretty easy to check how any LLVM IR you've added manually with `llvmcall` is fitting in with the Julia-generated IR around it using `@code_llvm`.

I can appreciate that perspective for sure.

Just to make sure we're on the same page though, it's perhaps worth clarifying that this particular integration issue isn't something you have to worry about every time you use two packages together (far from it), it's only in the case where you're trying to use a custom type from one package (e.g., one which replaces base Arrays or base Numbers or such) in functions from another package.

Well I don't think it's hard any more than writing any other sort of test in a given language. That doesn't mean it doesn't require expertise in that language.