4 ms·

> 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 a

> 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.

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.