6 ms·

So when I wrote my piece complaining about how people should not try to compare Go and Rust as they were created for very different purposes, people kept commen

So when I wrote my piece complaining about how people should not try to compare Go and Rust as they were created for very different purposes, people kept commenting that I was attacking a problem that I had came up with myself, and yet here's one more comparison of that kind reaching the front page of hn. To me the question in the title is as ill posed as would be "Choosing Between C or JavaScript?".

yazboo 7y ago
This article makes the point you were apparently making, that Go and Rust are created for very different purposes. The difference is in the framing: this article is not complaining about people posing a question, it's providing useful information to people who don't already know everything.
nwmcsween 7y ago
Eh go can be a fill in for things you would do in c, just as rust can be as well, Different strokes or whatnot
sramsay 7y ago
Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist. And let me explain. This guy has been "at a startup" and "at a Golang Meetup." If that isn't thought leadership, I don't know what is.
- Animats 7y ago
  Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist. Good point. It's a very light article, written for people who listen to Thot Leaders. It misses most of the important points. Go is designed for web back ends. It has all the stuff you need for that, and the libraries have been thoroughly pounded on and debugged, because Google uses them internally. The language is stable and doesn't change much. It's a good fit to that job. For other applications, Go may or may not be a good fit. Desktop apps? Probably not. Games? Probably not. Real-time control? No. Rust now seems to be trying to use every cool idea around, all at once. The borrow checker was brilliant. The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! We have a whole bunch of different HTTP libraries! We've changed the error handling system how many times now? It's all very cleverly done. But it's overdone. I'm out of that world, and not clear on whether there are signs of it settling down yet.
  - dmit 7y ago
    > Thot Leaders That's a completely different industry, I think. > The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! Generics, lambdas, and threads are must-have basics. Futures and async are the same thing. Rust doesn't "have functional programming", unless you mean chaining `map` and `collect` methods, in which case Java also has functional programming. HTTP and error handling are third-party libraries. Multiple choices in this area are a direct result of not trying to bundle the kitchen sink with the language. These things don't standardize in a year.
  - heavenlyblue 7y ago
    The issue with Rust is that people actually like using it. So there’s a bunch of development happening purely for enjoyment: why is that an issue? Nobody’s forcing you to keep up with the trends - just stick to the older versions of the libraries and it’ll simply work.
    - Animats 7y ago
      Is there a winner in the HTTP Rust library wars yet? The last time I used Rust, Hyper was on top, but I hear it's no longer cool. "reqwest" is being talked up. You can also get several versions of the same library in the same program through dependency problems.[1] This is a process problem. The development process for Rust does not seem to force convergence. [1] https://hackernoon.com/programming-in-rust-the-good-the-bad-the-ugly-d06f8d8b7738 https://hackernoon.com/programming-in-rust-the-good-the-bad-...
      - steveklabnik 7y ago
        Reqwest is an easier-to-use wrapper around Hyper. By the same authors.
      - jamwt 7y ago
        It's... been hyper for years and is still hyper. Reqwest is an ergonomic wrapper on top of hyper if you want a higher-level API with less control. Among the Rust ecosystem things to gripe about, this is a odd one. async_std vs. tokio is the real split-investment battleground these days, effectively undermining the async/await momentum right as it gets out of the gate.
- krebs_liebhaber 7y ago
  "Thought Leader" gives me cultist vibes, with a hint of multi-level marketing. If you write some more shallow, keyword-laden dreck to get us some of that sweet, sweet SEO JUICE[1], you could be a Double Black Diamond as well!!! [1] https://youtu.be/3bARSNVobUk?t=420 https://youtu.be/3bARSNVobUk?t=420
pizza234 7y ago
There some bad judgment around, due, in my opinion, to a couple of main reasons: - heavy Go marketing, which (intendedly or not) makes devs think that Go is "great at everything": you can't tweak memory management? that's a feature¹. - simplified/misguided categorization into old language models: Golang is the new C, Rust is the new C++. I think with a long enough time, the roles of the two languages will become significantly clearer. ¹: to clarify, that's a feature in some contexts, but not in others (therefore, not appropriate for "everything").
- dan_quixote 7y ago
  > I think with a long enough time, the roles of the two languages will become significantly clearer. I also expect this to be the case. But when I try to think of historical context, I come up blank. Was there this much polarization between languages in the past? I remember similar rumblings between Java and C# like 15-20 years ago, but that had more to do with the corporate backing and licensing IIRC. This feels more like political/tribal arguing.

yazboo 7y ago

This article makes the point you were apparently making, that Go and Rust are created for very different purposes. The difference is in the framing: this article is not complaining about people posing a question, it's providing useful information to people who don't already know everything.

nwmcsween 7y ago

Eh go can be a fill in for things you would do in c, just as rust can be as well, Different strokes or whatnot

sramsay 7y ago

Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist. And let me explain. This guy has been "at a startup" and "at a Golang Meetup." If that isn't thought leadership, I don't know what is.

Animats 7y ago
Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist. Good point. It's a very light article, written for people who listen to Thot Leaders. It misses most of the important points. Go is designed for web back ends. It has all the stuff you need for that, and the libraries have been thoroughly pounded on and debugged, because Google uses them internally. The language is stable and doesn't change much. It's a good fit to that job. For other applications, Go may or may not be a good fit. Desktop apps? Probably not. Games? Probably not. Real-time control? No. Rust now seems to be trying to use every cool idea around, all at once. The borrow checker was brilliant. The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! We have a whole bunch of different HTTP libraries! We've changed the error handling system how many times now? It's all very cleverly done. But it's overdone. I'm out of that world, and not clear on whether there are signs of it settling down yet.
- dmit 7y ago
  > Thot Leaders That's a completely different industry, I think. > The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! Generics, lambdas, and threads are must-have basics. Futures and async are the same thing. Rust doesn't "have functional programming", unless you mean chaining `map` and `collect` methods, in which case Java also has functional programming. HTTP and error handling are third-party libraries. Multiple choices in this area are a direct result of not trying to bundle the kitchen sink with the language. These things don't standardize in a year.
- heavenlyblue 7y ago
  The issue with Rust is that people actually like using it. So there’s a bunch of development happening purely for enjoyment: why is that an issue? Nobody’s forcing you to keep up with the trends - just stick to the older versions of the libraries and it’ll simply work.
  - Animats 7y ago
    Is there a winner in the HTTP Rust library wars yet? The last time I used Rust, Hyper was on top, but I hear it's no longer cool. "reqwest" is being talked up. You can also get several versions of the same library in the same program through dependency problems.[1] This is a process problem. The development process for Rust does not seem to force convergence. [1] https://hackernoon.com/programming-in-rust-the-good-the-bad-the-ugly-d06f8d8b7738 https://hackernoon.com/programming-in-rust-the-good-the-bad-...
    - steveklabnik 7y ago
      Reqwest is an easier-to-use wrapper around Hyper. By the same authors.
    - jamwt 7y ago
      It's... been hyper for years and is still hyper. Reqwest is an ergonomic wrapper on top of hyper if you want a higher-level API with less control. Among the Rust ecosystem things to gripe about, this is a odd one. async_std vs. tokio is the real split-investment battleground these days, effectively undermining the async/await momentum right as it gets out of the gate.
krebs_liebhaber 7y ago
"Thought Leader" gives me cultist vibes, with a hint of multi-level marketing. If you write some more shallow, keyword-laden dreck to get us some of that sweet, sweet SEO JUICE[1], you could be a Double Black Diamond as well!!! [1] https://youtu.be/3bARSNVobUk?t=420 https://youtu.be/3bARSNVobUk?t=420

pizza234 7y ago

There some bad judgment around, due, in my opinion, to a couple of main reasons: - heavy Go marketing, which (intendedly or not) makes devs think that Go is "great at everything": you can't tweak memory management? that's a feature¹. - simplified/misguided categorization into old language models: Golang is the new C, Rust is the new C++. I think with a long enough time, the roles of the two languages will become significantly clearer. ¹: to clarify, that's a feature in some contexts, but not in others (therefore, not appropriate for "everything").

dan_quixote 7y ago
> I think with a long enough time, the roles of the two languages will become significantly clearer. I also expect this to be the case. But when I try to think of historical context, I come up blank. Was there this much polarization between languages in the past? I remember similar rumblings between Java and C# like 15-20 years ago, but that had more to do with the corporate backing and licensing IIRC. This feels more like political/tribal arguing.