They claim they are writing the actual kernel code (as in the implementation of a matmul) with it, and it was presented as a "system programming language": this goes far beyond "high-level tasks" it seems.

You can write kernels in a language with a GC. You just write kernels that don't allocate.

Alternatively have the GC as an OS service.

Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.

I have wanted deterministic timing in Julia for years. It's come up periodically in the forums.

That, and optimized static binaries, would make Julia truly general purpose.

I don't mind Python syntax, I hope Mojo lives up to all these claims...it could easily (and finally!) hit the sweet spot of C performance, elegance, and expressiveness!

What’s your use case for this? Do you mean like a real-time Julia?

Yes. There are already efforts in that direction, such as Julia Robotics (juliarobotics.org).

With Julia, there is work to be done to get to small, optimized, static binaries - which it sounds like Mojo will provide out of the box, given it’s targeting resource-constrained (and novel) hardware.

The Rust-inspired features are also VERY interesting!

This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.

Julia is already being used in a number of systems with varying levels of real-time-ness. It's early days for sure, but there's a bunch of progress. It turns out lots of "real time" applications actually just need fast code. JIT compile also can be overcome since in real time systems, you generally know all the code you are going to call so you can just make a .so with all of those bits compiled and know that nothing will need to be compiled at runtime.

Also on a related topic, the PR for parallel GC in Julia just merged 4 days ago (https://github.com/JuliaLang/julia/pull/48600), so GC is in the process of getting a bunch faster.

> Julia is already being used in a number of systems with varying levels of real-time-ness.

Any examples you could link to?

The coolest I know of is ASML putting Julia on their giant chip making machines https://www.youtube.com/watch?v=EafTuyy7apY. I think there's also work on putting Julia on satellites, but I don't have the details.

Note that in Julia 1.9 (rc3 currently) and thanks to `PrecompileTools.jl` being adopted by the vast majority of the packages, the compilation latency is a dead issue... (ok, it is moved to the package installation time...)

PrecompileTools.jl has definitely not been adopted by the "vast majority of packages" and compilation latency is not a dead issue. There's been huge progress, and the rate of progress on this is much higher than before, but let's not get ahead of ourselves.

That is not really true. People think that because they have spent time with Java which is excessively GC dependent. More modern GC languages such as Go and Julia have opted to use GCs in a far more conservative manner. They don't produce the exorbitant amount of garbage that Java produces. I've talked to NASA guys using Go for real time systems. They say it works great. GC doesn't need to be a problem if you do it right.

A JIT works perfectly alright for real time applications, PTC and Aicas are still in business.

What matters is how it is implemented, naturally a general purpose one won't do it.

Yes, I'm not saying it's not possible, but real time abilities were likely one of the least important aspects of Julia's design... So why shoehorn it into something it's not been designed for

After the 1st JIT-compilation (which here we treat as C++ static compilation), there is no compilation cost. As long as you avoid doing dynamic things (e.g. GC), there's a great case to be made for real time Julia.

Of course, but other than in C++ you need to use ways and means to achieve this - never hitting u compiled code - that are not very natural to Julia. Yes it may be possible to compile Julia code to binaries, but it obviously is neither straightforward nor widely used.

You could do a lot worse than modern GC. For instance, in Rust, lack of GC may cause you to reallocate memory or use reference counting, both of which are likely slower than GC. For instance, building a tree in Rust will do a lot of reference counting, which is a lot of heap accesses.

> building a tree in Rust will do a lot of reference counting

This isn't true in most cases. If every subtree is only referenced by its (unique) parent, then you can use a standard Rust "Box", which means that during compilation, the compiler inserts calls to malloc() (when the Box is created) and free() (when the Box goes out of scope). There will be no reference counting — or any other overhead — at runtime.

Tree based structures with root ownership are very constrained as general purpose data structure.