7 ms·

What a disappointment.

by mietek 12y ago

kibwen 12y ago
Can you elaborate?
- smosher_ 12y ago
  Fwiw I think we were all disappointed when all that work and attention on a promising mechanism for having it both ways ultimately came to nothing.
  - kibwen 12y ago
    I concur. But I don't regret the time spent experimenting. Even negative results are valuable for advancing the state of the art.
    - smosher_ 12y ago
      Yeah, I'm just trying to describe the above poster as reasonable before other readers jump on the opportunity to white-out the comment for no good reason.
- mietek 12y ago
  There is not much to say which has not already been said. I think it is sad that so much effort is going into projects which do not advance the state of the art. First Go, now Rust — these high-profile projects draw people’s attention away from actually innovative work. As a core contributor, you will retort that Rust has different priorities than, say, Erlang, which is built around the concept of providing N:M processes (green threads) as a language primitive. My answer to that is, why not improve on Erlang, instead of settling for improving on C?
  - bjz_ 12y ago
    Because we actually have to release something. And you can't be all things to all people. The best we can do is try to create a powerful, safe, extensible language, low overhead language with unsafe escape hatches. The hope is that this will allow for future advances in lightweight, task based concurrency in the form of libraries, as opposed to as baked-in language features.
  - dbaupp 12y ago
    It is unfortunate that you think Rust is not improving the state of the art: no other language is low-level and memory safe, with the same flexibility as Rust. Rust is certainly pushing the research envelope further than Go, and, anyway, it seems to me that improving on C is something very desirable given the recent spate of horrible bugs in C libraries, caused by memory safety violations (heartbleed etc).
  - kibwen 12y ago
    It's understandable that you think that I'm a core contributor, but I'm really just an informed community member. I have no vested stake in Rust, and I'm not afraid to criticize the core team when they make baffling decisions (example: the tone-deaf new syntax for fixed-length arrays). And just because Rust has a focus on pragmatism doesn't mean that it's not blazing new territory. Neither Ada nor Cyclone can boast such extensively useful statically-safe references. And figuring out how to do unboxed closures memory-safely in a language without a garbage collector is, as far as I can tell, entirely novel (though you'd have to ask a PL researcher to be certain). I expect aspects of Rust to show up in all future systems programming languages, including future revisions of C++ (as well as brand-new efforts such as M#).
    - mietek 12y ago
      We already have a systems programming language with a garbage collector. http://dl.acm.org/citation.cfm?id=367177.367199 http://dl.acm.org/citation.cfm?id=367177.367199
thomasahle 12y ago
I like it. Platform threads should just be lightweight enough, that you don't have to patch on top of them. And if you really need to M:N behaviour, it is still available as a library.
- rubiquity 12y ago
  Agreed. Defaulting to native threading gives developers so much more freedom. After all, M:N threading is just implemented on native threads anyway. You can still do that if you want to. Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. This change was necessary to keep Rust as a general use systems programming language.
  - dragonwriter 12y ago
    > Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. M:N threading decouples degree of concurrency from degree of parallelism, which is not desirable only for networking. And the old way wasn't about forcing M:N threading, it was about providing a common interface for concurrency independent of the relation of concurrency to parallelism in the backend implementation. I can understand the idea that that abstraction may have been too expensive, but I can't get behind the idea that 1:1 threading as the only thing supported in the standard library somehow provides more freedom for developers.
    - dbaupp 12y ago
      Short-term it may look like there's less freedom since it's harder to use M:N threading (and 1:1 threading and M:N threading don't necessarily work perfectly together), but remember that the choice there is 1:1 threading with overhead and M:N threading with overhead. Long term, we can have libraries that provide M:N threading with minimal overhead; and also libraries that provide 1:1 & M:N together like the old std (with the associated overhead). That is, the programmer is getting more flexibility, just not right now (especially with Cargo, which makes it particularly easy to use external libraries). The team is trying to take a longer term view focusing std on safe interfaces to the OS primitives, which can then be used to build fancier/more abstract libraries more easily.

What a disappointment.

by mietek 12y ago

What a disappointment.

kibwen 12y ago

Can you elaborate?

smosher_ 12y ago
Fwiw I think we were all disappointed when all that work and attention on a promising mechanism for having it both ways ultimately came to nothing.
- kibwen 12y ago
  I concur. But I don't regret the time spent experimenting. Even negative results are valuable for advancing the state of the art.
  - smosher_ 12y ago
    Yeah, I'm just trying to describe the above poster as reasonable before other readers jump on the opportunity to white-out the comment for no good reason.
mietek 12y ago
There is not much to say which has not already been said. I think it is sad that so much effort is going into projects which do not advance the state of the art. First Go, now Rust — these high-profile projects draw people’s attention away from actually innovative work. As a core contributor, you will retort that Rust has different priorities than, say, Erlang, which is built around the concept of providing N:M processes (green threads) as a language primitive. My answer to that is, why not improve on Erlang, instead of settling for improving on C?
- bjz_ 12y ago
  Because we actually have to release something. And you can't be all things to all people. The best we can do is try to create a powerful, safe, extensible language, low overhead language with unsafe escape hatches. The hope is that this will allow for future advances in lightweight, task based concurrency in the form of libraries, as opposed to as baked-in language features.
- dbaupp 12y ago
  It is unfortunate that you think Rust is not improving the state of the art: no other language is low-level and memory safe, with the same flexibility as Rust. Rust is certainly pushing the research envelope further than Go, and, anyway, it seems to me that improving on C is something very desirable given the recent spate of horrible bugs in C libraries, caused by memory safety violations (heartbleed etc).
- kibwen 12y ago
  It's understandable that you think that I'm a core contributor, but I'm really just an informed community member. I have no vested stake in Rust, and I'm not afraid to criticize the core team when they make baffling decisions (example: the tone-deaf new syntax for fixed-length arrays). And just because Rust has a focus on pragmatism doesn't mean that it's not blazing new territory. Neither Ada nor Cyclone can boast such extensively useful statically-safe references. And figuring out how to do unboxed closures memory-safely in a language without a garbage collector is, as far as I can tell, entirely novel (though you'd have to ask a PL researcher to be certain). I expect aspects of Rust to show up in all future systems programming languages, including future revisions of C++ (as well as brand-new efforts such as M#).
  - mietek 12y ago
    We already have a systems programming language with a garbage collector. http://dl.acm.org/citation.cfm?id=367177.367199 http://dl.acm.org/citation.cfm?id=367177.367199

thomasahle 12y ago

I like it. Platform threads should just be lightweight enough, that you don't have to patch on top of them. And if you really need to M:N behaviour, it is still available as a library.

rubiquity 12y ago
Agreed. Defaulting to native threading gives developers so much more freedom. After all, M:N threading is just implemented on native threads anyway. You can still do that if you want to. Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. This change was necessary to keep Rust as a general use systems programming language.
- dragonwriter 12y ago
  > Rust isn't going to be a systems language used only for networking, so forcing a M:N threading model on it doesn't make sense. M:N threading decouples degree of concurrency from degree of parallelism, which is not desirable only for networking. And the old way wasn't about forcing M:N threading, it was about providing a common interface for concurrency independent of the relation of concurrency to parallelism in the backend implementation. I can understand the idea that that abstraction may have been too expensive, but I can't get behind the idea that 1:1 threading as the only thing supported in the standard library somehow provides more freedom for developers.
  - dbaupp 12y ago
    Short-term it may look like there's less freedom since it's harder to use M:N threading (and 1:1 threading and M:N threading don't necessarily work perfectly together), but remember that the choice there is 1:1 threading with overhead and M:N threading with overhead. Long term, we can have libraries that provide M:N threading with minimal overhead; and also libraries that provide 1:1 & M:N together like the old std (with the associated overhead). That is, the programmer is getting more flexibility, just not right now (especially with Cargo, which makes it particularly easy to use external libraries). The team is trying to take a longer term view focusing std on safe interfaces to the OS primitives, which can then be used to build fancier/more abstract libraries more easily.