3 ms·

Parallelism is too hard in C, easier in Go, but Rust makes it too easy and is therefore poorly designed? What kind of an argument is this?

by jolux 6y ago

Animats 6y ago
Yes. I have criticisms of Rust, but not that one. We have to go parallel for things that need speed. CPUs are not getting faster, but we have far more cores. Now this is more of a problem: - C: 0.73 new features per year - Go: 2 new features per year - C++: 11.3 new features per year - Rust: 15 new features per year Rust is now stable enough that you can recompile old programs from a few years ago, but more and more features are being added and the ideomatic usage keeps changing. The borrow checker was brilliant. The rest of the language, not so much. A point that doesn't get discussed enough is threading models. Go has "green threads" - no need for a distinction between threading and "async". Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. "Green threads" have been around for years, but Go seems to be the first language where they really took off. This may reflect the use case. Go is optimized for big web servers talking to huge numbers of clients, which is what Google does all day.
- jcranmer 6y ago
  The feature comparison is bullshit because the author uses different methodologies to count the features of Rust compared to the other three languages. For the other languages, it's count the bullet points in a list of new features; for Rust, it's count the bullet points in release notes. (And the methodology isn't clear as to whether it's limiting to language features, or including both library and language features) > Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. Rust started with green threads, but they were removed pre-1.0 for reasons that I'm sure steveklabnik can jump in and explain.
  - steveklabnik 6y ago
    Yeah, I would strongly disagree with "bashed into the language as an afterthought" Here is a very lengthy explanation of the reasons: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/
- mumblemumble 6y ago
  > We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished each of the following at least once: Sped up a concurrent implementation by making it parallel. Sped up a concurrent implementation by making it sequential. Sped up a parallel implementation by making it concurrent. Sped up a parallel implementation by making it sequential. Sped up a sequential implementation by making it concurrent. Sped up a sequential implementation by making it parallel. The 2nd and 4th ones are often the easiest to accomplish. Amdahl's law is a great rule of thumb, but it subtly implies an idealized world where both the transition between sequential and parallelizable sections of the process, and the communication among parallel sections, happen at zero cost. The real world is messy, though, so, in practice, they can get pretty expensive. Parallelism can slow things down by introducing extra copying, memory access, memory fences, conditional branches, etc. You've got to dig yourself out of that hole before you can realize any gains. To the extent that the term "order of magnitude" often comes into play when describing the sizes of delays these things can cause, it can be a pretty deep hole.
- masklinn 6y ago
  > "Green threads" have been around for years, but Go seems to be the first language where they really took off. Java used to be based around green threads back in the early day. Lua's concurrency is based around coroutines. OCaml's OS threads are hampered by a GIL so concurrency is generally done via lwt or Async. And of course "green threads" are the very base of erlang / elixir. And Haskell has… Sparks, I think? You could argue that they're not as popular as Go but then… ok? > This may reflect the use case. It definitely does. Rust used to use green threads and everything way back in the olden days. That was stripped out, because it's inimical to being the low-level language its community wanted it to be. If you want to use green threads, you must have some sort of runtime to manage them (scheduling and preempting, maintaining the task queues, …), and probably a GC because this makes the lifecycle of your values way harder to predict and square. But the environment where the Rust community of the time wanted to use Rust did not allow for such overhead. So out they went, to be added later as an opt-in.
- Ar-Curunir 6y ago
  async was not "bashed into the language as an afterthought". The design of async took a lot of time, and was done very carefully to try and fit a niche that very few other languages manage to do: zero-overhead, ergonomic, and safe abstractions for futures.
- pornel 6y ago
  This header counting is silly. Regular complaints about Rust changing too much have stopped after Rust website stopped having such detailed release notes. Seriously. People who don't know Rust don't understand how bare-bones 1.0 was, and that Rust is still filling in gaps in basic functionality. Rust is still catching up with features Go 1.0 had, but people praise Go for being small, while freaking out about Rust getting bloated. This doesn't make sense! Most of the changes can be summed up "previously code that you'd expect to work didn't work for weird complex reasons, but now we've fixed it and it compiles". Things like `clone()` didn't work on arrays larger than 32 elements. Now it works, as it should have since 1.0. But by Drew's header count that's some frivolous added complexity. > Rust started with threads, and are having "async" bashed into the language as an afterthought. Afterthought? That feature was over 3 years in the making. It was probably the most scrutinized and bikeshedded feature Rust ever had. Rust team has explored various approaches, with prototypes implemented in the compiler. People have built an entire ecosystem on Futures 0.1 to work out all the kinks of the design in large production-ready projects. Proto-Rust had green threads and removed them for a good reason. The trade-offs are well understood, and it's not a coincidence that Go doesn't have zero-cost interoperability with C, and Rust has (including cross-language inlining).
  - Animats 6y ago
    "It's not a coincidence that Go doesn't have zero-cost interoperability with C, and Rust has (including cross-language inlining." That's more of a money issue. Google has the resources to rewrite the lower layers in or for Go. Mozilla doesn't. Mozilla was trying to retrofit a single existing program, too.
    - steveklabnik 6y ago
      This is not true; it has to do with ideology. As a systems language, Rust should be able to talk to systems with no overhead. A zero-cost FFI into C is a huge part of that ability. Nowhere in https://github.com/rust-lang/rfcs/pull/230 https://github.com/rust-lang/rfcs/pull/230 is Mozilla mentioned, nor expenses.

Parallelism is too hard in C, easier in Go, but Rust makes it too easy and is therefore poorly designed? What kind of an argument is this?

by jolux 6y ago

Parallelism is too hard in C, easier in Go, but Rust makes it too easy and is therefore poorly designed? What kind of an argument is this?

Animats 6y ago

Yes. I have criticisms of Rust, but not that one. We have to go parallel for things that need speed. CPUs are not getting faster, but we have far more cores. Now this is more of a problem: - C: 0.73 new features per year - Go: 2 new features per year - C++: 11.3 new features per year - Rust: 15 new features per year Rust is now stable enough that you can recompile old programs from a few years ago, but more and more features are being added and the ideomatic usage keeps changing. The borrow checker was brilliant. The rest of the language, not so much. A point that doesn't get discussed enough is threading models. Go has "green threads" - no need for a distinction between threading and "async". Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. "Green threads" have been around for years, but Go seems to be the first language where they really took off. This may reflect the use case. Go is optimized for big web servers talking to huge numbers of clients, which is what Google does all day.

jcranmer 6y ago
The feature comparison is bullshit because the author uses different methodologies to count the features of Rust compared to the other three languages. For the other languages, it's count the bullet points in a list of new features; for Rust, it's count the bullet points in release notes. (And the methodology isn't clear as to whether it's limiting to language features, or including both library and language features) > Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. Rust started with green threads, but they were removed pre-1.0 for reasons that I'm sure steveklabnik can jump in and explain.
- steveklabnik 6y ago
  Yeah, I would strongly disagree with "bashed into the language as an afterthought" Here is a very lengthy explanation of the reasons: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/
mumblemumble 6y ago
> We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished each of the following at least once: Sped up a concurrent implementation by making it parallel. Sped up a concurrent implementation by making it sequential. Sped up a parallel implementation by making it concurrent. Sped up a parallel implementation by making it sequential. Sped up a sequential implementation by making it concurrent. Sped up a sequential implementation by making it parallel. The 2nd and 4th ones are often the easiest to accomplish. Amdahl's law is a great rule of thumb, but it subtly implies an idealized world where both the transition between sequential and parallelizable sections of the process, and the communication among parallel sections, happen at zero cost. The real world is messy, though, so, in practice, they can get pretty expensive. Parallelism can slow things down by introducing extra copying, memory access, memory fences, conditional branches, etc. You've got to dig yourself out of that hole before you can realize any gains. To the extent that the term "order of magnitude" often comes into play when describing the sizes of delays these things can cause, it can be a pretty deep hole.
masklinn 6y ago
> "Green threads" have been around for years, but Go seems to be the first language where they really took off. Java used to be based around green threads back in the early day. Lua's concurrency is based around coroutines. OCaml's OS threads are hampered by a GIL so concurrency is generally done via lwt or Async. And of course "green threads" are the very base of erlang / elixir. And Haskell has… Sparks, I think? You could argue that they're not as popular as Go but then… ok? > This may reflect the use case. It definitely does. Rust used to use green threads and everything way back in the olden days. That was stripped out, because it's inimical to being the low-level language its community wanted it to be. If you want to use green threads, you must have some sort of runtime to manage them (scheduling and preempting, maintaining the task queues, …), and probably a GC because this makes the lifecycle of your values way harder to predict and square. But the environment where the Rust community of the time wanted to use Rust did not allow for such overhead. So out they went, to be added later as an opt-in.
Ar-Curunir 6y ago
async was not "bashed into the language as an afterthought". The design of async took a lot of time, and was done very carefully to try and fit a niche that very few other languages manage to do: zero-overhead, ergonomic, and safe abstractions for futures.
pornel 6y ago
This header counting is silly. Regular complaints about Rust changing too much have stopped after Rust website stopped having such detailed release notes. Seriously. People who don't know Rust don't understand how bare-bones 1.0 was, and that Rust is still filling in gaps in basic functionality. Rust is still catching up with features Go 1.0 had, but people praise Go for being small, while freaking out about Rust getting bloated. This doesn't make sense! Most of the changes can be summed up "previously code that you'd expect to work didn't work for weird complex reasons, but now we've fixed it and it compiles". Things like `clone()` didn't work on arrays larger than 32 elements. Now it works, as it should have since 1.0. But by Drew's header count that's some frivolous added complexity. > Rust started with threads, and are having "async" bashed into the language as an afterthought. Afterthought? That feature was over 3 years in the making. It was probably the most scrutinized and bikeshedded feature Rust ever had. Rust team has explored various approaches, with prototypes implemented in the compiler. People have built an entire ecosystem on Futures 0.1 to work out all the kinks of the design in large production-ready projects. Proto-Rust had green threads and removed them for a good reason. The trade-offs are well understood, and it's not a coincidence that Go doesn't have zero-cost interoperability with C, and Rust has (including cross-language inlining).
- Animats 6y ago
  "It's not a coincidence that Go doesn't have zero-cost interoperability with C, and Rust has (including cross-language inlining." That's more of a money issue. Google has the resources to rewrite the lower layers in or for Go. Mozilla doesn't. Mozilla was trying to retrofit a single existing program, too.
  - steveklabnik 6y ago
    This is not true; it has to do with ideology. As a systems language, Rust should be able to talk to systems with no overhead. A zero-cost FFI into C is a huge part of that ability. Nowhere in https://github.com/rust-lang/rfcs/pull/230 https://github.com/rust-lang/rfcs/pull/230 is Mozilla mentioned, nor expenses.