ulysses4ever

It does have similar formulation but the setting is completely different. Types in Julia are not the same thing as types in statically typed languages with dependent types. In those languages you can elegantly declare the connection between inputs and outputs, and moreover the connection will be checked. In Julia type stability is a property of a code that Julia compiler will discover on its own during runtime. The programmer can't declare it nor have it checked.

You can use Unions, and in fact that's what Julia do. The issue is performance -- that's what the paper advocates: stable (grounded, more precisely) functions are a clear cut in terms of optimization. Unstable ones is a lottery (sometimes Julia does a decent Job at optimizing them sometimes not).

Rust is an interesting example, maybe I should look into the library. But the compilation model is very different from probably any JIT, including Julia. Optimizations too. For one, unions (enums) in Rust would have much less profound impact on possible optimizations and therefore performance.

I absolutely agree that providing a tool to _assert_ stability (just like usual @assert) would be great. We thought about it when writing the paper but never got to device anything like that. For smooth integration, that would probably require hacking on Julia itself.

In the paper, we provide several thoughts, including one example, when type _in_stability actually makes sense. In particular, the example concerns a typical `parse` function, that converts a string into an AST node. Assuming you have one struct per AST type, the parse function is unstable.

Generally, several well-known OOP design patterns would naturally lead to instability. In turn, those patterns can be handy to solve certain typical problems. If you have such a problem at hand, you have a choice: either do a well-known thing and embrace instability (which is actually not always all that harmful for performance), or get out of your way and torture your code to make it stable…

That's my bad then. I think I might have thought Zenodo link would be enough. But now I think it's a bad idea. Probably will add the GH link in an update.

Hey! we're tracking JET.jl and think that it's great already and may become even better. We hope to base some of our future stuf off it. Some of us (not me) actually work on a trait design. Multiple inheritance -- not so much: we think it would preclude some important optimizations and that way defeat the whole purpose of Julia (performance + dynamism).

This may require more thinking on our end but the way we design Jules is the usual SSA form. The idea being it's easier to reason about it (and prove things) when every expression has a name. It's a bit of cheating of course but makes our life easier. We don't discuss how surface Julia (or subset of it), which is more expression-oriented, can be translated to Jules, because we have only so many pages, and also it's not all that interesting, I think.

Your intuition is right but _every_ expression is bound by a variable in this representation.

I think the link's supposed to be in the text but the repo is here: https://github.com/prl-julia/julia-type-stability There's a PDF there explaining how to get started with it and repro the graphs but it shouldn't be too hard to utilize it for the purpose you mention. We never got around to writing that kind of docs (for package developers) properly unfortunately. Feel free to open issues against the repo if you have troubles using it!

You're quite right about the organic nature. The story of how we get together could be better told by our prof, Jan Vitek, I guess. But in a nutshell, one of his older students (Ben, also an author of the paper) was once on a plane with some other student, Jean, from MIT, where Julia was developed, and Ben got interested and told Jan… Then there were occasional meetings with Julia devs (Jeff Bezanson in particular) that turned out to be super nice and inviting people. I should add, we're all from Northeastern University in Boston, and that's close to MIT... All in all, we decided PL academia should learn about this "organic gem".

Author here. AMA!

Fleets of servers suffer from constant “configuration drift”, making any incremental change to their state hazardous. Will an upgrade that worked yesterday work today? Will it work for you if it worked for me? We’re never quite sure…

The solution: miniaturizing the inputs to your lab experiment and to your build bots, the state of your laptop and of your resources in the cloud, using precise, shareable, composable declarative specifications.