Ivan do you have any insight why rust is popular?

CPUSpeedup

Ivan I remember you distinctly saying you've done 11 compilers and languages don't make any money. I can agree the rust compiler/language hasn't "made" any money but I wasn't sure if you were also saying compilers don't make money?

My real question is do you have any insights to why rust is "popular"? Is rust popular according to your definition? I don't like the language for a number of reasons but it's annoying how much people bring it up and how much they 'like' it (although I'm pretty sure most barely use it) and it appears 'popular'.

ivan

Sorry, I have no idea. I work well below the language level, and have never used Rust in particular.

pingveno

Speaking of Rust, it would be interesting to at some point get support for the Mill architecture. The Rust compiler uses LLVM as a backend, so on a technical level it should be relatively easy to add support. Rust has a tier support system, so introducing a tier 3 target is a relatively low bar. Rust does have a patched version of LLVM bundled with it, so that might cause some issues.

ivan

The compiler aspect is no problem; I'd expect the present tool chain to handle it with minimal effort. However, Rust needs its own runtime, and this is likely to be a piece of work on a machine with secure stacks; you can't just muck directly with the stack links on a Mill.

I agree that it would be an interesting and useful project. We've had several requests for Rust beyond your own, but no one yet has stepped forward and offered to join the team and port Rust. Offers, anyone?

pingveno

When you're talking about stack links, are you referring to how segmented stacks are implemented? Those were dropped from Rust a few years back. Panics also need a handler, which defaults to a shared implementation based on libunwind. However, I think an MVP could instead just abort and leave unwinding to be implemented later. Normal operations would need some work on things like compiler intrinsics. I would offer to get involved, but I have no real experience in compilers so this would be far beyond my comfort level.

ivan

Presumably the language translations aspects are already handled by LLVM Rust, and the LLVL/IR-to-genAsm step handles all IR already, so the task can assume valid genAsm input and never look inside the compiler. The specializer handles all generic IR already, so that leaves on the intrinsics and whatever runtime is directly called.

That is where the work is: figuring out how a particular intrinsic/runtime behavior should be implemented in a Mill, probably initially by writing a function for it that does not itself use the intrinsics. There's already specializer logic to replace an arbitrary intrinsic with a native function call, but the function body still has to be written; that needs an understanding of the machine but not of compilers. Some existing intrinsics are replaced by in-line code rather than by function calls, and that requires a greater understanding of how things are represented in the specializer, but there are plenty of examples and that optimization can be deferred anyway.

So the task is not really a compiler task; it's a runtime system task. And it may be an OS kernel task - remember that the tool chain drops code on the bare machine, not on a Linux loader with an OS behind it. Done right, the kernel itself could be written in Rust.

But only if there's someone willing to take it on :-)