5 ms·

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/o

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...)
  - vvanders 10y ago
    Rust is actually much closer to unique_ptr than shared_ptr or weak_ptr. The use of Rc is pretty small in practice. The thing is that even with unique_ptr I can easily reach in via get() and I've broken the shared mutable state contract. It's trivial for me to trace what modifies things in Rust, I just follow the 'mut' annotations and since only one thing can hold it at a time it's very straightforward. Rust also has one the best package managers I've seen. Union types which are the best way to represent states and state machines bar none. An iterator class that's the best I've seen(seriously has anyone actually used <algorithm>? How man begin/end pairs do I need?). Plus the community is super-welcoming, there's more reasons but those are my top ones right now.
  - pjmlp 10y ago
    The magic is that there is no way to enforce that in modern C++, in spite of current attempts. There will always be that compiler or team that doesn't have any kind of reviews, static analysis, making use of binary libraries or legacy code. Hence why safety at language level is much better than third party tooling, as tools can be ignored.
  - coldtea 10y ago
    >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 Who said it does? And why would it have to? It'a just about catching those "certain class of errors that the Rust compiler will check that will still give you a segfault in C++". Plus a nicer looking language, with a more modern design.
  - dbaupp 10y ago
    The more strict static checking in Rust means that the compiler can actually be a teaching tool for concepts like RAII and the heap/stack difference: it flags and explains places where the programmer is doing that doesn't make sense in those settings. A lot of effort has been put into the compiler diagnostics to make this compiler-is-a-teacher concept a reality.
steveklabnik 10y ago
Rust is aiming for more than an incremental improvement. Take Servo, for example. The goal is to provide a generational leap in rendering engines, and while it's not done yet, the initial results are promising. I agree that "salvation" is a bit much, though. For whatever hype Go had and may have, it's still a resoundingly successful language that's building meaningful stuff that improves people's lives. Sounds like a success to me.
stcredzero 10y ago
A few years ago it was "concurrency primitives are going to change your life Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing. 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. There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel? 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. Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study? If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.
- rch 10y ago
  > There's something wrong with programming as an entire field Look at all the research and prototyping in aviation. What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products.
  - stcredzero 10y ago
    What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products. I like that very much! Also strange are the obscurity and outright myths surrounding heavily engineered products, followed by hyped reinvention.
- bjz_ 10y ago
  Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study? [...] If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes. Graydon has consistently pointed out Rusts influences, indeed it is one of the reasons behind its name - ie. 'rusty old ideas'. But the influences of the creator are not enough. We need to promote the value of a historical perspective in our discourse, and so I I'm glad for your post. As a young developer I see it in my peers, but even sadder I also see it in my mentors and elders. So often there is two extremes of fervent excitement and lack of imagination that things could be better beyond ones own experience... both borne out of a lack of historical literacy. That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. But perhaps they could get better faster with fewer steps backwards with a little schooling on the foundations of our field.
jstewartmobile 10y ago
If we were betting money, I'd put mine on Golang over Rust just because of the piles of money and effort Google keeps pouring into it. Rust is a little cooler, but I just don't see Mozilla having enough resources to keep-up the momentum long-term.
- kmicklas 10y ago
  These piles of money don't seem to be amounting to much because rust is still an objectively far superior language. Google is not a language company and doesn't hire good language people so I don't see this changing. Disclaimer: I work for Google
  - jstewartmobile 10y ago
    No argument on superior, it's just that superior doesn't win the day. Look at C++. Look at JavaScript. It would be surprising if the industry made the better choice for a change.
    - kmicklas 10y ago
      Yeah but unlike, say, Haskell, Rust seems to have good enough momentum from the right crowds.
    - eropple 10y ago
      Hmm--with some edge-case exceptions that never got a strong push outside of some niches (Ada comes to mind, where it achieved some traction in DoD circles), I wonder if C++ wasn't the superior choice given its time and place. By no means is it perfect, but in the early to mid 90's there weren't many competitors with a similar feature set that had anybody pushing hard behind it. To my mind it seems not dissimilar. If I have to write native code, right now it'll be C++ precisely because it's able to express complex problems with a high degree of getting-it-right (because while I would never claim to understand C++, I feel confident in my understanding of the subset of C++ that I use). I really like Rust and look forward to it being a better fit for what I want to do, and every time I look at it it's getting closer.
to3m 10y ago
Move semantics, man. I don't personally divide my life into "before move semantics" and "after move semantics" - but thanks to move semantics, I have to anyway. And I feel like I'm all the better for it.
coldtea 10y ago
>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 Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?
foota 10y ago
But rust reuses some tooling, for instance, llvm.

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...)
- vvanders 10y ago
  Rust is actually much closer to unique_ptr than shared_ptr or weak_ptr. The use of Rc is pretty small in practice. The thing is that even with unique_ptr I can easily reach in via get() and I've broken the shared mutable state contract. It's trivial for me to trace what modifies things in Rust, I just follow the 'mut' annotations and since only one thing can hold it at a time it's very straightforward. Rust also has one the best package managers I've seen. Union types which are the best way to represent states and state machines bar none. An iterator class that's the best I've seen(seriously has anyone actually used <algorithm>? How man begin/end pairs do I need?). Plus the community is super-welcoming, there's more reasons but those are my top ones right now.
- pjmlp 10y ago
  The magic is that there is no way to enforce that in modern C++, in spite of current attempts. There will always be that compiler or team that doesn't have any kind of reviews, static analysis, making use of binary libraries or legacy code. Hence why safety at language level is much better than third party tooling, as tools can be ignored.
- coldtea 10y ago
  >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 Who said it does? And why would it have to? It'a just about catching those "certain class of errors that the Rust compiler will check that will still give you a segfault in C++". Plus a nicer looking language, with a more modern design.
- dbaupp 10y ago
  The more strict static checking in Rust means that the compiler can actually be a teaching tool for concepts like RAII and the heap/stack difference: it flags and explains places where the programmer is doing that doesn't make sense in those settings. A lot of effort has been put into the compiler diagnostics to make this compiler-is-a-teacher concept a reality.

steveklabnik 10y ago

Rust is aiming for more than an incremental improvement. Take Servo, for example. The goal is to provide a generational leap in rendering engines, and while it's not done yet, the initial results are promising. I agree that "salvation" is a bit much, though. For whatever hype Go had and may have, it's still a resoundingly successful language that's building meaningful stuff that improves people's lives. Sounds like a success to me.

stcredzero 10y ago

A few years ago it was "concurrency primitives are going to change your life Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing. 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. There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel? 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. Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study? If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.

rch 10y ago
> There's something wrong with programming as an entire field Look at all the research and prototyping in aviation. What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products.
- stcredzero 10y ago
  What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products. I like that very much! Also strange are the obscurity and outright myths surrounding heavily engineered products, followed by hyped reinvention.
bjz_ 10y ago
Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study? [...] If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes. Graydon has consistently pointed out Rusts influences, indeed it is one of the reasons behind its name - ie. 'rusty old ideas'. But the influences of the creator are not enough. We need to promote the value of a historical perspective in our discourse, and so I I'm glad for your post. As a young developer I see it in my peers, but even sadder I also see it in my mentors and elders. So often there is two extremes of fervent excitement and lack of imagination that things could be better beyond ones own experience... both borne out of a lack of historical literacy. That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. But perhaps they could get better faster with fewer steps backwards with a little schooling on the foundations of our field.

jstewartmobile 10y ago

If we were betting money, I'd put mine on Golang over Rust just because of the piles of money and effort Google keeps pouring into it. Rust is a little cooler, but I just don't see Mozilla having enough resources to keep-up the momentum long-term.

kmicklas 10y ago
These piles of money don't seem to be amounting to much because rust is still an objectively far superior language. Google is not a language company and doesn't hire good language people so I don't see this changing. Disclaimer: I work for Google
- jstewartmobile 10y ago
  No argument on superior, it's just that superior doesn't win the day. Look at C++. Look at JavaScript. It would be surprising if the industry made the better choice for a change.
  - kmicklas 10y ago
    Yeah but unlike, say, Haskell, Rust seems to have good enough momentum from the right crowds.
  - eropple 10y ago
    Hmm--with some edge-case exceptions that never got a strong push outside of some niches (Ada comes to mind, where it achieved some traction in DoD circles), I wonder if C++ wasn't the superior choice given its time and place. By no means is it perfect, but in the early to mid 90's there weren't many competitors with a similar feature set that had anybody pushing hard behind it. To my mind it seems not dissimilar. If I have to write native code, right now it'll be C++ precisely because it's able to express complex problems with a high degree of getting-it-right (because while I would never claim to understand C++, I feel confident in my understanding of the subset of C++ that I use). I really like Rust and look forward to it being a better fit for what I want to do, and every time I look at it it's getting closer.

to3m 10y ago

Move semantics, man. I don't personally divide my life into "before move semantics" and "after move semantics" - but thanks to move semantics, I have to anyway. And I feel like I'm all the better for it.

coldtea 10y ago

>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 Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?

foota 10y ago

But rust reuses some tooling, for instance, llvm.