undefined

points

[-]

As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves.

Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.

by skavi11 hours ago|

parent|

[-]

All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.

by afdbcreid15 hours ago|

parent|

prev|

[-]

Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.

by throwaway20373 hours ago|

parent|

prev|

[-]

    > But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative.

What "space"? My guess: HFT or HPC.

by wrxd1 hours ago|

parent|

[-]

Their message begins with "As an embedded dev"

by tialaramex1 hours ago|

parent|

[-]

"embedded" is very vague though. The problem is that both the guy writing PIC machine code for a $5 thermostat and the guy who wrote some Python running on the Linux box inside a Times Square moving advert think they're "an embedded dev".

by pjmlp16 hours ago|

prev|

[-]

From what I could understand regarding Sean Parent's last interview at ADSP, Hylo is most likely not happening at all, given the raise of AI tooling, with Dave Abrahams re-focusing into non-computing related work going forward,

https://adspthepodcast.com/2026/08/21/Episode-300.html

Cpp2 was Herb's experiment and doesn't seem to be developed much further now,

https://github.com/hsutter/cppfront/discussions/1450

Google is still quite keen in having Carbon, for the purpose of migrating existing C++ codebases, for new code there is Rust, Go, Kotlin, Java, Swift and co.

"Carbon: graduating from the experiment - NDC Toronto 2026"

https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9

by hiccuphippo17 hours ago|

prev|

[-]

> other two famous Handmade languages

Jai and... C3? FilC?

by tialaramex12 hours ago|

parent|

[-]

Jai and C3. I do not consider FilC to be a distinct programming language. AIUI the C I wrote twenty years ago would work with Filip's approach, maybe it needs minor tweaks in a few cases (mmap stunts for example) but likely not for much of what I wrote.

by zamalek17 hours ago|

prev|

[-]

To Odin's credit, it is used for production software that _isn't_ a toy (by the language's own authors). It is probably 1.0 quality already.

by tialaramex13 hours ago|

parent|

[-]

If you want to imagine a "1.0 quality" which means "Is used in some software that isn't a toy" then all kinda of crap counts. Bill has given specific goals, I don't think he'll meet them or perhaps even understands how high those bars are†, but even by his understanding Odin hasn't reached those goals.

Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use.

One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired.

† In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.

by afdbcreid16 hours ago|

parent|

prev|

[-]

Zig too. But this is far from being mainstream. Rust took around 5 years I think to become accepted in major companies, and those languages are harder to justify.

by zamalek12 hours ago|

parent|

[-]

I've started distrusting anything good people have to say about Zig because of the wide variety of untrue claims made about it - unless those claims come from Andrew himself. Last time I was assured that compile-time memory guarantees were possible and were going to happen (they didn't: the recent announcement is runtime/debug assertions). Zig is still making massive breaking changes, and while that is not a bad thing, it makes it categorically _not_ production ready.

by pjmlp2 hours ago|

parent|

[-]

Also note that isn't much different from debug heap that MSCV was already having in 2000[0], assuming you didn't want to shell out some money to Insure++{1], BoundsChecker[2] and similar products.

Or something like SoftBound, from 2009,

https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf

It hasn't been for lack of choice.

[0] - https://learn.microsoft.com/en-us/cpp/c-runtime-library/debu...

[1] - https://www.parasoft.com/products/parasoft-insure/

[2] - https://en.wikipedia.org/wiki/BoundsChecker

by 4k0hz9 hours ago|

prev|

[-]

[dead]