I also sorta remember some kernel developers (not necessarily Linux) making a fuss about rustc using a huge amount of address space and not working on 32-bit systems for that reason - although frankly, I can't remember where I read that and I'm starting to question how much I'm misremembering there.
You might be thinking of Theo de Raadt: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
And I hope other projects don't trade off safety/productivity/etc. for portability to obscure hobby architectures.
Blanketing every architecture LLVM doesn't support that GCC does an "obscure hobby architecture" is not really a great way to look at things imo. I haven't looked into it but I'm pretty sure outside the bubble of desktop computers there are plenty of important uses of Linux on less common architectures, I would assume mostly embedded systems.
Some of my favourite things about Ada is it's approach to concurrency, which (I think) is far superior to other imperative concurrent languages like Go. We should never have to deal with low-level primitives like semaphores and mutexes - it's 2018! Why are we stuck in the 80s?
I've heard that concurrency is difficult in Rust, but I've never used it, so I can't comment. I plan on learning very soon!
Semaphores are not typed. They is no semantic connection to the thing they protect. Debugging concurrent systems with mutual exclusion enforced through these low-level primitives is a nightmare.
If you forgot to lock/unlock, you'll never know! The compiler cannot check it. Deadlocks are imminent.
We've had better abstractions since the 80s. Conditional critical regions, monitors, and (ideally) protected objects. Hell, even guards are better than semaphores and mutexes - at least they are associated with their critical region!
I struggle to think of situations where a semaphore is the best choice. Maybe in extremely high-performance cases, but even then the compiler can usually make a better decision.
This is the whole point of the borrow checker which is to ensure data-race free code.
The story with concurrency is still being worked out with async server-side applications which is coming together swimmingly!
That's awesome! I never knew Rust had safer concurrency. I'm quite keen to learn it - just waiting for the time.
Go has channels, which is nice enough for message-passing behaviour, but nothing for elegantly sharing memory. ("Share memory by communicating" doesn't always work)
Things like conditional critical regions, monitors, and protected objects are much better abstractions for concurrency.
D
Which is fine, since D is supposed to be a better C.
I wouldn't consider its concurrent primitives comparable to Ada. This is to be expected, since I don't believe they aim for such a nuanced level of concurrency. The Ada runtime is incredibly huge and complex - it was created by the US military, after all.
Concurrency in Rust is not difficult (neither complex nor error-prone), but you have some high-level primitives that you must know how to choose and use.