11–19 of 19 posts
Not sure how good the original article is, but this is a poor rant. And I very much dislike Go as a language.
It comes across like: "X-Drink is better than Y-Drink, even though I've never tasted Y-Drink!"
Kudos to them for admitting that fact at least, I guess?
I'm a heavy Go user and light Rust user. I enjoy them both, and they gives me different set of advantages in return.
Please, don't use/treat comparisons as an attack, make it "So-this-can-help-me-do-that".
> Ah crap, not that shit again.
> The whole point is "compiler is fast, tests run faster". Well, what if I said the compiler would catch bugs before the tests? That would be even faster, 'cause then you can focus your tests on system behaviour, which is way more important than function behaviour or class/structure/module behaviour.
No.
A fast compiler is not only good for unit tests. And even when it comes to unit tests, it is not at all idiomatic Rust to omit them; on the contrary, unit test support is built into the language!
Rust having a slow compiler is a serious downside. The language has many upsides that can hopefully make up for it, depending on your priorities, but that doesn't make compilation speed a non-issue.
That said, the compiler is significantly faster than it used to be and hopefully will continue to improve as time goes on.
Earlier quoted context omitted.
Programming languages are tools that require significant career investment. Sure you can learn the basics in a 21 Days[1], but that's not going to land you a Senior Developer salary. You're choosing a horse to ride for many years, and if you chose the wrong horse, you're going to find yourself in a crimp. But horses/languages don't have value in a vacuum. They have value because the industry recognizes them. You'll h…
But Rust and Go have different goals. If there was ever a definition of apples to oranges, Rust and Go would be it.
Not sure how good the original article is, but this is a poor rant. And I very much dislike Go as a language.
Both of these languages make people feel passionate in a way that other languages do not, and so we will continue to see these kinds of discussions, which I think is a good thing.
Better to have the overall software development community lively and engaged with the tools than cynical or disinterested.
> You know who has Google problems? GOOGLE! You know who else has Google problems? NO ONE!
That's true, but guess what, Google still uses C++ and Java for the vast majority of its critical infrastructure. So even at Google, C++ and Java reign supreme at handling "Google scale". And it's not surprising really, the maturity, performance, tooling, etc. available for Java and C++ are far superior to what golang has to offer. Not to mention both being far better languages than golang (even with how complex C++ is). golang is a weak language not suited for modeling complex domains.
Secondly, golang was developed by some employees at Google, not Google itself. And if it weren't for the brand name behind it, it would have gone nowhere.
Really who cares? Pick a language. They are both fine. Both will probably solve whatever problem you have without too many issues. Arguing over which one you should use its probably pointless 99% of the time. I wish I had a link to the twitter exchange between both accounts where the answer they both agreed with was learn both, and lets have this conversation in a week. It feels 100% relevant here.
> learn both This is a common advice but it isn't realistic. It takes a lot of time to learn a language, its tools, its most popular libraries, its best practices, to interact with its community, to see in what problem domains it shines, etc. I'd say you need to give it more than a year, more than two if you're not doing it on the job. You can churn code much sooner than that obviously, that's not what we are taking…