6 ms·

The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for

The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for every startup that failed using it. Ruby survived it, and I'm sure Rust will too, but that doesn't make it obnoxious for everyone else who inevitably gets swept up in the craze and crash. Programming is hard. Programming will always be hard. Better/newer tools (and sometimes influences from the old finally making it mainstream, like Standard ML) make programming easier but not fool proof. It's misleading and harmful to hype the crap out of any language. Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.

w8rbt 10y ago
I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.
- jdright 10y ago
  And it is not. It is not faster than C but it can be almost as fast someday.
  - w8rbt 10y ago
    The rust zealots say it is, "Better performance than C" That's from the linked article 'Rust is Software's Salvation' (bullet point 3).
- averell 10y ago
  That is very much possible in many cases. Zero cost abstractions exist: https://blog.rust-lang.org/2015/05/11/traits.html https://blog.rust-lang.org/2015/05/11/traits.html
- nitroll 10y ago
  It is, especially if these checks are done at compile time, not at runtime.
  - 102910201 10y ago
    Expect a blog post within four hours "Rust has solved the halting problem!"...
    - prodigal_erik 10y ago
      Even when you can't prove what arbitrary code does, proving what well-written code does is useful, and not writing unprovable code would be a small price to pay.
  - berkut 10y ago
    How can checks be done if the size is dynamic based on run-time data?
    - prodigal_erik 10y ago
      "Integer between 0 and n-1 inclusive" is the type of valid indices for an n element array. The trouble is most languages don't have type systems that allow expressing that.
      - pjmlp 10y ago
        The Pascal family are such languages.
- vvanders 10y ago
  Performance comes from being cache aware and having control over allocations moreso than safety checks. Maybe not faster than C but at least as fast while bringing modern patterns and better safety.
- EugeneOZ 10y ago
  It's possible: http://2015.splashcon.org/event/splash2015-tutorials-concurrency-in-rust-data-race-safety-with-zero-cost-abstractions http://2015.splashcon.org/event/splash2015-tutorials-concurr...
- deleted 10y ago
  [deleted]
- kstrauser 10y ago
  That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way. That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do. Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.
  - comex 10y ago
    Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.
    - burntsushi 10y ago
      rayon probably deserves a mention here: http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/ http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo... (It's not built in, but that's a good thing IMO. :-))
- wongarsu 10y ago
  >Rust claims to be faster than C and safer than C at the same time. That's not possible. Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C. I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.
  - pjmlp 10y ago
    Attempted multiple times, always ignored by the C crowd.
- coldtea 10y ago
  >Rust claims to be faster than C and safer than C at the same time. That's not possible. It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.
blowski 10y ago
I agree. We are making the same mistakes Fred Brooks talks about in "No Silver Bullets".
jeffdavis 10y ago
Do you have any suggestion to maintain hype at a reasonable level? Basically, a lot of people are excited about it, a lot of people are writing good libraries, and they blog about them, which feeds into the hype cycle. I think the main hype danger for rust right now is that the number of killer applications written it will fall short of the hype. But the linked article is from someone writing redox-os, so it's hard to criticize this article specifically for contributing to overhype. Ruby had the opposite problem, which is that a lot of people were writing amazing applications, but it fell down technically (applications got messier and slower; or at least that is the perception). In theory the same thing could happen to rust, but it seems less likely.
spacelizard 10y ago
The echoes of Golang hype right now are somewhat ominous. A few years ago it was "concurrency primitives are going to change your life" and now it's "lifetime/ownership primitives are going to change your life." I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.
- vvanders 10y ago
  I think you'll find a lot of Rust's supporters actually come from a Systems Programmers background who've felt the pain before. I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well. All my green-field code now is Rust. Sure there's some hype but that's because people are genuinely excited about the language.
  - spacelizard 10y ago
    I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you.
    - steveklabnik 10y ago
      For one, additional safety. Rust's equivalent are more safe. Secondly, speed. Rust has several advantages: with shared_ptr, for example, you have the Rc/Arc split, the decreased number of refcount bumps, etc. (some of that speed comes from the safety, even...)
slowrabbit 10y ago
Programming isn't hard, it is super easy. Most of the things we ask machines to do are sequences of simple steps. It's so easy in fact that children do it successfully with little training. Programming well can be hard but only because of the limitations of our current tools. Rust is a good step in the direction of safer systems programming and the people who are hyped about Rust are the smartest people in the room, just like with Bitcoin when it started.
- zaphar 10y ago
  That's like saying painting isn't hard it's easy. Children do it all the time with just their fingers. Painting a Mona Lisa is hard but only because we don't have good tooling. It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.
bjz_ 10y ago
> Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well. I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]: > Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it. Not all of us feel the need to sugar coat Rust. [0]: https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwares_salvation/dbrwlfa/ https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...
joshmarlow 10y ago
Why dear Sir, it almost sounds like you are suggesting that there is no silver bullet!
pjmlp 10y ago
As Alan Kay says, we have moved from a technical community to a pop driven one, so these hype cycles will never end while this mentality carries on. Having said this, Go got its killer application in the form of the main language driving container implementations. Rust might eventually get its one beyond the current browser implementation and get adopted by an OS vendor. Just with Apple doing Swift, Microsoft .NET Native and C++/GSL, maybe it is left for Google and their Fuchsia project or an embedded OS vendor to do it.

w8rbt 10y ago

I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.

jdright 10y ago
And it is not. It is not faster than C but it can be almost as fast someday.
- w8rbt 10y ago
  The rust zealots say it is, "Better performance than C" That's from the linked article 'Rust is Software's Salvation' (bullet point 3).
averell 10y ago
That is very much possible in many cases. Zero cost abstractions exist: https://blog.rust-lang.org/2015/05/11/traits.html https://blog.rust-lang.org/2015/05/11/traits.html
nitroll 10y ago
It is, especially if these checks are done at compile time, not at runtime.
- 102910201 10y ago
  Expect a blog post within four hours "Rust has solved the halting problem!"...
  - prodigal_erik 10y ago
    Even when you can't prove what arbitrary code does, proving what well-written code does is useful, and not writing unprovable code would be a small price to pay.
- berkut 10y ago
  How can checks be done if the size is dynamic based on run-time data?
  - prodigal_erik 10y ago
    "Integer between 0 and n-1 inclusive" is the type of valid indices for an n element array. The trouble is most languages don't have type systems that allow expressing that.
    - pjmlp 10y ago
      The Pascal family are such languages.
vvanders 10y ago
Performance comes from being cache aware and having control over allocations moreso than safety checks. Maybe not faster than C but at least as fast while bringing modern patterns and better safety.
EugeneOZ 10y ago
It's possible: http://2015.splashcon.org/event/splash2015-tutorials-concurrency-in-rust-data-race-safety-with-zero-cost-abstractions http://2015.splashcon.org/event/splash2015-tutorials-concurr...
deleted 10y ago
[deleted]
kstrauser 10y ago
That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way. That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do. Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.
- comex 10y ago
  Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.
  - burntsushi 10y ago
    rayon probably deserves a mention here: http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/ http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo... (It's not built in, but that's a good thing IMO. :-))
wongarsu 10y ago
>Rust claims to be faster than C and safer than C at the same time. That's not possible. Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C. I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.
- pjmlp 10y ago
  Attempted multiple times, always ignored by the C crowd.
coldtea 10y ago
>Rust claims to be faster than C and safer than C at the same time. That's not possible. It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.

blowski 10y ago

I agree. We are making the same mistakes Fred Brooks talks about in "No Silver Bullets".

jeffdavis 10y ago

Do you have any suggestion to maintain hype at a reasonable level? Basically, a lot of people are excited about it, a lot of people are writing good libraries, and they blog about them, which feeds into the hype cycle. I think the main hype danger for rust right now is that the number of killer applications written it will fall short of the hype. But the linked article is from someone writing redox-os, so it's hard to criticize this article specifically for contributing to overhype. Ruby had the opposite problem, which is that a lot of people were writing amazing applications, but it fell down technically (applications got messier and slower; or at least that is the perception). In theory the same thing could happen to rust, but it seems less likely.

spacelizard 10y ago

The echoes of Golang hype right now are somewhat ominous. A few years ago it was "concurrency primitives are going to change your life" and now it's "lifetime/ownership primitives are going to change your life." I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.

vvanders 10y ago
I think you'll find a lot of Rust's supporters actually come from a Systems Programmers background who've felt the pain before. I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well. All my green-field code now is Rust. Sure there's some hype but that's because people are genuinely excited about the language.
- spacelizard 10y ago
  I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you.
  - steveklabnik 10y ago
    For one, additional safety. Rust's equivalent are more safe. Secondly, speed. Rust has several advantages: with shared_ptr, for example, you have the Rc/Arc split, the decreased number of refcount bumps, etc. (some of that speed comes from the safety, even...)

slowrabbit 10y ago

Programming isn't hard, it is super easy. Most of the things we ask machines to do are sequences of simple steps. It's so easy in fact that children do it successfully with little training. Programming well can be hard but only because of the limitations of our current tools. Rust is a good step in the direction of safer systems programming and the people who are hyped about Rust are the smartest people in the room, just like with Bitcoin when it started.

zaphar 10y ago
That's like saying painting isn't hard it's easy. Children do it all the time with just their fingers. Painting a Mona Lisa is hard but only because we don't have good tooling. It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.

bjz_ 10y ago

> Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well. I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]: > Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it. Not all of us feel the need to sugar coat Rust. [0]: https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwares_salvation/dbrwlfa/ https://www.reddit.com/r/rust/comments/5kytg5/rust_is_softwa...

joshmarlow 10y ago

Why dear Sir, it almost sounds like you are suggesting that there is no silver bullet!

pjmlp 10y ago

As Alan Kay says, we have moved from a technical community to a pop driven one, so these hype cycles will never end while this mentality carries on. Having said this, Go got its killer application in the form of the main language driving container implementations. Rust might eventually get its one beyond the current browser implementation and get adopted by an OS vendor. Just with Apple doing Swift, Microsoft .NET Native and C++/GSL, maybe it is left for Google and their Fuchsia project or an embedded OS vendor to do it.