3 ms·

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: Rust gets a lot closer than Go, but is still straddling this awkward territory

Been following Rust and bitc. I'll leave bitc alone and instead comment on Rust: 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.

masklinn 15y ago
> 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. 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.
- heretohelp 15y ago
  Then it might work out fine, I don't know. 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.
  - kibwen 15y ago
    Your hunch is correct, Rust's developers have stated that Rust isn't aiming to be a language with which to implement kernels or device drivers.[1] 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. [1] https://github.com/mozilla/rust/wiki/Doc-project-FAQ https://github.com/mozilla/rust/wiki/Doc-project-FAQ
  - icebraining 15y ago
    I'm not saying Rust will "fail" like Go seems to be doing so far 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?
    - ootachi 15y ago
      Go isn't failing. It's actually doing quite well. I disagree with the design and implementation of almost every part of the language, but credit where credit is due: Google has created a language that a lot of people like.
pcwalton 15y ago
So we basically use the runtime for three things: (a) the task system, which features lightweight threads like Go or Erlang; (b) stack checks and growth; (c) garbage collection. We used to use it for more, but lately more and more stuff has been moved out of the runtime to be written in Rust itself. 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.

masklinn 15y ago

> 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. 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.

heretohelp 15y ago
Then it might work out fine, I don't know. 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.
- kibwen 15y ago
  Your hunch is correct, Rust's developers have stated that Rust isn't aiming to be a language with which to implement kernels or device drivers.[1] 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. [1] https://github.com/mozilla/rust/wiki/Doc-project-FAQ https://github.com/mozilla/rust/wiki/Doc-project-FAQ
- icebraining 15y ago
  I'm not saying Rust will "fail" like Go seems to be doing so far 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?
  - ootachi 15y ago
    Go isn't failing. It's actually doing quite well. I disagree with the design and implementation of almost every part of the language, but credit where credit is due: Google has created a language that a lot of people like.

pcwalton 15y ago

So we basically use the runtime for three things: (a) the task system, which features lightweight threads like Go or Erlang; (b) stack checks and growth; (c) garbage collection. We used to use it for more, but lately more and more stuff has been moved out of the runtime to be written in Rust itself. 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.