5 ms·

> libstd is that much closer to being used in a "bare metal" context. It's still aways off, but we're getting closer every day! This is so cool. Most programm

> libstd is that much closer to being used in a "bare metal" context. It's still aways off, but we're getting closer every day! This is so cool. Most programming language implementations come with a lot of baggage. They assume that the VM can stop the world, or that the VM will be in control of all threading, or that the VM will use global variables, or that the VM can move objects around in memory whenever it feels like it. VMs like this are like demanding houseguests that insist that everything conform to their expectations. VMs like this are not easy to embed and do not "play nicely" with other software. Doing the work to factor these assumptions out of the core language/VM/implementation and into libraries is not easy work, but you end up with something so much more versatile. Lua is this way, and of course C. It sounds like Rust is going this route too, and that's so cool to see.

jerf 13y ago
On the flip side, though, those assumptions are also what lets a runtime actually do things for you. In the limit, a runtime that assumes nothing is simply machine language. Even C has a runtime, whose assumptions can be violated quite thoroughly by other languages. The less the language actually specifies, the more likely you are to encounter the situation where two Rust libraries can't work together because they actually work under Rust-Alpha (some twiddling of the knobs) and Rust-Beta (some other incompatible twiddling of the knobs). I don't know that this is a problem for Rust yet, but it is the first announcement from the Rust team which has actually dropped my level of interest in the language. Is there recognition that this is a tradeoff and not something you can think of as purely a "feature"? Do they realize that this was a huge step towards potential fragmentation of the language? (Not just in this particular decision, either, but the general mindset that leads towards this decision leads to fragmentation.)
- mtanski 13y ago
  This strikes me a pragmatic decision driven by wanting to reduce complexity and be interoperable with 3rd party libraries (mostly C code). If you read my other comment here, I outlined the problems I ran into with the N:M threading model (although mostly in C land). It strikes me as Rust ran into the same issues. I'm beginning to think that you can't make N:M well unless you take the approach that language X itself is the platform and everything needs to be done in language X. Java has taken this approach (yes I knot there's the JNI -- we know how fun to use it us -- but the Java community is pretty bent on writing almost everything in Java). Go seams to be going that direction by rewriting all the standard library, runtime and compilers slowly in Go. I don't know Erlang's stance on this. It looks like Rust is taking the approach of we want to be a systems language AND we want to be interoperable with tons of existing 3rd party code (which implies mostly other C libraries). P.S: Nice to see you commenting here Jermey. It's been a long time since we talked (cuda days).
  - jerf 13y ago
    "I don't know Erlang's stance on this." Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly trivially so. It doesn't have synchronization problems because it basically doesn't have synchronization. (In the OS sense. Of course your user code may have various sync concerns, but there's no OS-level race conditions, or memory race conditions, etc.) It pays for these characteristics, but also reaps various benefits. (It's a pity that I don't know of any great single chunk of documentation on the Erlang VM I can point to; links solicited. It's such a different beast. Someone interested in learning about how it's different without necessarily learning Erlang would probably better just studying the VM itself.) P.S.: Yo, 'sup.
    - pcwalton 13y ago
      > Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.
      - jlouis 13y ago
        I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.
        pcwalton 13y ago
        > If Rust has a single large shared heap for all proceses, then the approach is different. Rust does not use one shared heap. Tasks cannot share memory (except through ARCs, which manage their own memory through atomic reference counting and so avoid garbage collection pauses). Garbage collection is completely local to a task, so while one task is collecting garbage other tasks are free to run.
- pcwalton 13y ago
  > The less the language actually specifies, the more likely you are to encounter the situation where two Rust libraries can't work together because they actually work under Rust-Alpha (some twiddling of the knobs) and Rust-Beta (some other incompatible twiddling of the knobs). We are explicitly trying to avoid this. Libraries should be able to work in M:N or 1:1 mode, or some combination of the two, without having to rewrite code. This change was carefully designed to allow this. > Do they realize that this was a huge step towards potential fragmentation of the language? We are very much intending to minimize fragmentation. Projects like alternative standard libraries are discouraged for this reason.
  - jerf 13y ago
    This relaxes me. It really was concern about fragmentation. While both D and Python seemed to have survived their bouts with fragmentation, for instance, it certainly seems to be a dangerous road to travel.
- cmrx64 13y ago
  On the contrary, this decision was solely motivated by the desire to reduce fragmentation. The interfaces libstd provides can work under almost any runtime, and (mostly, but definitely in safe code) don't leak implementation details. Needing a different standard library just to have a different runtime model is unacceptable. A lot of work has gone and is going into ensuring that we do not fragment. We know that fragmentation will kill us.
- andrewflnr 13y ago
  A nice high-level way to express machine code has a lot of value.
- haberman 13y ago
  > Even C has a runtime, whose assumptions can be violated quite thoroughly by other languages. C has a little wrapper around main(), and it has a standard library, but it has no runtime to speak of.
  - qznc 13y ago
    The C runtime consists of stuff like malloc and free. Newer versions of C also require support for thread-local storage for example. It is not a lot, but there definitly is a small runtime called libc. Of course, the C standard also defines the freestanding variant, but there is not even main() anymore.
    - justincormack 13y ago
      Its barely a runtime though. I prefer to view Unix as the runtime for C...
    - haberman 13y ago
      A standard library is not the same as a runtime. A library you explicitly call out to, and if you do not call it you can avoid linking the library at all. A runtime inserts calls to itself in a way that cannot be reasonably avoided, and must therefore be linked/loaded by every program.
  - tokenrove 13y ago
    That little wrapper is a runtime (after all, what does crt stand for?); depending on the platform, it's certainly not so negligible that you can say it doesn't exist.
    - haberman 13y ago
      It is not a runtime in the ways that matter. After it has transferred control to the user program, it is gone completely; it never inserts itself into the program's execution. It is more like the loader or dynamic linker of the OS than like the runtime of other languages. If you have your own mechanism for transferring control to the C program you don't need the main() wrapper at all.

jerf 13y ago

On the flip side, though, those assumptions are also what lets a runtime actually do things for you. In the limit, a runtime that assumes nothing is simply machine language. Even C has a runtime, whose assumptions can be violated quite thoroughly by other languages. The less the language actually specifies, the more likely you are to encounter the situation where two Rust libraries can't work together because they actually work under Rust-Alpha (some twiddling of the knobs) and Rust-Beta (some other incompatible twiddling of the knobs). I don't know that this is a problem for Rust yet, but it is the first announcement from the Rust team which has actually dropped my level of interest in the language. Is there recognition that this is a tradeoff and not something you can think of as purely a "feature"? Do they realize that this was a huge step towards potential fragmentation of the language? (Not just in this particular decision, either, but the general mindset that leads towards this decision leads to fragmentation.)

mtanski 13y ago
This strikes me a pragmatic decision driven by wanting to reduce complexity and be interoperable with 3rd party libraries (mostly C code). If you read my other comment here, I outlined the problems I ran into with the N:M threading model (although mostly in C land). It strikes me as Rust ran into the same issues. I'm beginning to think that you can't make N:M well unless you take the approach that language X itself is the platform and everything needs to be done in language X. Java has taken this approach (yes I knot there's the JNI -- we know how fun to use it us -- but the Java community is pretty bent on writing almost everything in Java). Go seams to be going that direction by rewriting all the standard library, runtime and compilers slowly in Go. I don't know Erlang's stance on this. It looks like Rust is taking the approach of we want to be a systems language AND we want to be interoperable with tons of existing 3rd party code (which implies mostly other C libraries). P.S: Nice to see you commenting here Jermey. It's been a long time since we talked (cuda days).
- jerf 13y ago
  "I don't know Erlang's stance on this." Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly trivially so. It doesn't have synchronization problems because it basically doesn't have synchronization. (In the OS sense. Of course your user code may have various sync concerns, but there's no OS-level race conditions, or memory race conditions, etc.) It pays for these characteristics, but also reaps various benefits. (It's a pity that I don't know of any great single chunk of documentation on the Erlang VM I can point to; links solicited. It's such a different beast. Someone interested in learning about how it's different without necessarily learning Erlang would probably better just studying the VM itself.) P.S.: Yo, 'sup.
  - pcwalton 13y ago
    > Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.
    - jlouis 13y ago
      I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.
      - pcwalton 13y ago
        > If Rust has a single large shared heap for all proceses, then the approach is different. Rust does not use one shared heap. Tasks cannot share memory (except through ARCs, which manage their own memory through atomic reference counting and so avoid garbage collection pauses). Garbage collection is completely local to a task, so while one task is collecting garbage other tasks are free to run.
pcwalton 13y ago
> The less the language actually specifies, the more likely you are to encounter the situation where two Rust libraries can't work together because they actually work under Rust-Alpha (some twiddling of the knobs) and Rust-Beta (some other incompatible twiddling of the knobs). We are explicitly trying to avoid this. Libraries should be able to work in M:N or 1:1 mode, or some combination of the two, without having to rewrite code. This change was carefully designed to allow this. > Do they realize that this was a huge step towards potential fragmentation of the language? We are very much intending to minimize fragmentation. Projects like alternative standard libraries are discouraged for this reason.
- jerf 13y ago
  This relaxes me. It really was concern about fragmentation. While both D and Python seemed to have survived their bouts with fragmentation, for instance, it certainly seems to be a dangerous road to travel.
cmrx64 13y ago
On the contrary, this decision was solely motivated by the desire to reduce fragmentation. The interfaces libstd provides can work under almost any runtime, and (mostly, but definitely in safe code) don't leak implementation details. Needing a different standard library just to have a different runtime model is unacceptable. A lot of work has gone and is going into ensuring that we do not fragment. We know that fragmentation will kill us.
andrewflnr 13y ago
A nice high-level way to express machine code has a lot of value.
haberman 13y ago
> Even C has a runtime, whose assumptions can be violated quite thoroughly by other languages. C has a little wrapper around main(), and it has a standard library, but it has no runtime to speak of.
- qznc 13y ago
  The C runtime consists of stuff like malloc and free. Newer versions of C also require support for thread-local storage for example. It is not a lot, but there definitly is a small runtime called libc. Of course, the C standard also defines the freestanding variant, but there is not even main() anymore.
  - justincormack 13y ago
    Its barely a runtime though. I prefer to view Unix as the runtime for C...
  - haberman 13y ago
    A standard library is not the same as a runtime. A library you explicitly call out to, and if you do not call it you can avoid linking the library at all. A runtime inserts calls to itself in a way that cannot be reasonably avoided, and must therefore be linked/loaded by every program.
- tokenrove 13y ago
  That little wrapper is a runtime (after all, what does crt stand for?); depending on the platform, it's certainly not so negligible that you can say it doesn't exist.
  - haberman 13y ago
    It is not a runtime in the ways that matter. After it has transferred control to the user program, it is gone completely; it never inserts itself into the program's execution. It is more like the loader or dynamic linker of the OS than like the runtime of other languages. If you have your own mechanism for transferring control to the C program you don't need the main() wrapper at all.