4 ms·

Classic: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”[1] The thing that bugs me is the comparison to Rust.

Classic: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”[1] The thing that bugs me is the comparison to Rust. I mean, the author did caveat that he chose it because Rust provided the best available counter examples to his specific gripes. But my issue is that comparison seems to make a false conclusion: Rust is better. My intuition says if the author used Rust (or any other language) as much as they have used Go, and in the same environments solving similar sized problems, they would have a completely different 1000+ word rant on all the things they hate about that language. We have an expression "use in anger". It describes a particular kind of understanding that only becomes available when we face the real problems and not just idealized ones. I even see smaller rants within this comment section showing how the very systems he lauds in Rust have sharp corners when used in anger. I thought this rant had many good points and highlights many shortcomings of Go. I would have preferred that it did not contain the comparison which draws an implicit conclusion that IMO is likely incorrect. 1. https://www.goodreads.com/quotes/226225-there-are-only-two-kinds-of-languages-the-ones-people https://www.goodreads.com/quotes/226225-there-are-only-two-k...

eximius 7y ago
Rust is better _at the problem presented_. Rust not being perfect does not mean other languages can learn from its successes.
- reggieband 7y ago
  > Rust is better _at the problem presented_. What I'm suggesting is that wasn't demonstrated. Go had a real-world used-in-anger problem. That was compared to an idealized solution in Rust. It seems to me that this is an unfair comparison. Fair enough, it is hard to demand anyone who wishes to make a comparison between two programming languages to have built equivalent massive systems that stretch each language to their limits. But the point of the article wasn't to compare languages, it was to show the kinds of problems exposed in Go when it is used in massive real-world systems. So maybe it would have been better to leave the comparison out.
  - eximius 7y ago
    > What I'm suggesting is that wasn't demonstrated. An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? I won't disagree that readers might make a leap to intuit the author thinks Rust is overall better. But that extra leap doesn't mean he failed to show Rust was better at a particular problem. In fact, that is WHY people would make that un-warranted leap. > But the point of the article wasn't to compare languages, it was to show the kinds of problems exposed in Go when it is used in massive real-world systems. I mean, not really. Cross platform file manipulation is, maybe not common, but not obscure. And making a web request reliably is also not something you'd expect to be only needed in massive systems.
    - reggieband 7y ago
      > An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? It isn't the same. There is another cheeky quote I can paraphrase: Everyone has a plan until they get punched in the face. He is comparing a Go implementation that has been punched in the face in a real-world use case against a Rust implementation that was sitting on the sidelines. If the point of the article (and the title) was "Go file system API vs Rust API, an in-depth analysis" I would not have made my comment. The thesis of the article appeared to be "pains I felt in Go when I used it on hard real-world problems". All of his points seem to stand completely fine when you remove the comparisons to Rust. For that reason I would have preferred to remove them.
      - eximius 7y ago
        You mean the Rust language that has dozens of cross platform implementations of coreutils binaries? Go might be larger, but I hardly think Rust qualifies as sitting on the sidelines. That's a fair opinion. I think the article is richer for having shown what a better API can look like for contrast.
nif2ee 7y ago
>There are only two kinds of languages: the ones people complain about and the ones nobody uses Repeating this quote again and again won't make it correct.
- terminaljunkid 7y ago
  The third kind is people use little bit and circlejerk that it solves world's problems, ivory tower elitism.
acdha 7y ago
No language is perfect but a couple of years ago I tried both. Learning Go was a constant stream of internalizing design failures and working around them (error handling, packages, etc.). Rust had some points which were harder to get started with but showed clear benefits for having done so — the difference between teaching you better habits versus not learning from C’s second greatest failure and viewing error handling as optional.

eximius 7y ago

Rust is better _at the problem presented_. Rust not being perfect does not mean other languages can learn from its successes.

reggieband 7y ago
> Rust is better _at the problem presented_. What I'm suggesting is that wasn't demonstrated. Go had a real-world used-in-anger problem. That was compared to an idealized solution in Rust. It seems to me that this is an unfair comparison. Fair enough, it is hard to demand anyone who wishes to make a comparison between two programming languages to have built equivalent massive systems that stretch each language to their limits. But the point of the article wasn't to compare languages, it was to show the kinds of problems exposed in Go when it is used in massive real-world systems. So maybe it would have been better to leave the comparison out.
- eximius 7y ago
  > What I'm suggesting is that wasn't demonstrated. An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? I won't disagree that readers might make a leap to intuit the author thinks Rust is overall better. But that extra leap doesn't mean he failed to show Rust was better at a particular problem. In fact, that is WHY people would make that un-warranted leap. > But the point of the article wasn't to compare languages, it was to show the kinds of problems exposed in Go when it is used in massive real-world systems. I mean, not really. Cross platform file manipulation is, maybe not common, but not obscure. And making a web request reliably is also not something you'd expect to be only needed in massive systems.
  - reggieband 7y ago
    > An in-depth analysis of the respective languages APIs for a particular targeted problem isn't enough? It isn't the same. There is another cheeky quote I can paraphrase: Everyone has a plan until they get punched in the face. He is comparing a Go implementation that has been punched in the face in a real-world use case against a Rust implementation that was sitting on the sidelines. If the point of the article (and the title) was "Go file system API vs Rust API, an in-depth analysis" I would not have made my comment. The thesis of the article appeared to be "pains I felt in Go when I used it on hard real-world problems". All of his points seem to stand completely fine when you remove the comparisons to Rust. For that reason I would have preferred to remove them.
    - eximius 7y ago
      You mean the Rust language that has dozens of cross platform implementations of coreutils binaries? Go might be larger, but I hardly think Rust qualifies as sitting on the sidelines. That's a fair opinion. I think the article is richer for having shown what a better API can look like for contrast.

nif2ee 7y ago

>There are only two kinds of languages: the ones people complain about and the ones nobody uses Repeating this quote again and again won't make it correct.

terminaljunkid 7y ago
The third kind is people use little bit and circlejerk that it solves world's problems, ivory tower elitism.

acdha 7y ago

No language is perfect but a couple of years ago I tried both. Learning Go was a constant stream of internalizing design failures and working around them (error handling, packages, etc.). Rust had some points which were harder to get started with but showed clear benefits for having done so — the difference between teaching you better habits versus not learning from C’s second greatest failure and viewing error handling as optional.