I'd like to see a "runtime-less Rust" myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.
If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help.
Yeah that's about what I'd expect considering the language's goals.
> Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.
Rust has the `unsafe` escape hatch for this, unsafe blocks can do whatever the hell they want and are "unsafe function" and "unsafe pointer" types which are known to bypass Rust's safety mechanism and can only be used in unsafe blocks.
In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.
If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.
I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].
[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.
It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.
I think it's way too early to tell if Go is failing or not; it was announced less than three years ago. How successful was, e.g. , Ruby in '98?
Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java.
I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for making it an excellent language for a database.
The non-optional runtime overhead that I have to imagine is endemic to the purported feature-set would seem to be a non-starter for systems (kernel, driver, embedded) programming.
Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.