Comment by lumost | Hacker News Reader

Comment by lumost | Hacker News Reader

Parent Full thread

Having worked in many languages including Go and Rust, I commonly see the following.

1. Team uses some interpreted language. This language is fine for most of their work, but causes performance problems and/or the team needs to do something performance sensitive.

2. Someone on the team proposes Go, often because it solves the performance problem - and is very simple to use. This proposal invites suggestions from the organizations programming language experts leading to "let's use lang X" suggestions. Often these suggestions have recommendations based on advanced programming language features such as high-order types, functional paradigms etc.

As Rust has been somewhat popular for backend services, you will find many suggestions of "let's use Rust." These discussions can often be less than civil. As I've aged - I've moved closer to the advanced language features camp - but I'd doubt that this is actually beneficial for productivity. It took me 3 attempts to learn the language and 5 years for Rust to feel productive - now it's my preferred language for side projects. Go took less than a day to pick up.

> It took me 3 attempts to learn the language and 5 years for Rust to feel productive - now it's my preferred language for side projects. Go took less than a day to pick up.

This is the bit people keep overlooking (maybe intentionally). Yes you, polyglot coder who knows 15 different programming languages and has 15 years of experience on the field can learn Rust in an afternoon and do a flawless solution on Advent of Code with it while learning.

But 99% of the people working in software (you know, all of the people outside FAANG and F500 companies) know exactly one language and have no interest in learning a new one, especially one that's really complex and full of fancy features they don't know what to do with.

I don't know if it's really still a fair trope at this point, but the argument made is that Go was specifically designed to be the best of Google's three main languages at the time— C++, Java, and Python. It was made to be quick to learn, hard to mess up, and easy to read/review. It specifically includes things like the build tool and formatter because those are long-running pain points in large scale development.

Rust, on the other hand, is a borderline research language that was built to support Servo, a web browser backend— literally among the hairiest of sofware engineering problems in existence. It gives you a lot of "safety" but at the cost of having to consider issues that most developers never think about.

This is not to say that Go is for dumb programmers and Rust is for smart ones or anything of that sort— just that despite years of evolution, both carry the DNA of their inception, and it shows.

This is exactly so. At the edge, the go community will debate whether the language should be used for a project at all. Whereas the rust community will ship something that only kinda sorta works - or takes performance above all as the primary motivator.

As a very experienced engineer, I like the idea of Rust being a go to for all problems. 10 years ago - I would have hated its complexity and cursed the TL who forced it on my project.

> This is not to say that Go is for dumb programmers and Rust is for smart ones or anything of that sort

Go ahead and say it; I don't mind being the dumb programmer who gets shit done.

After all,

> Rust, on the other hand, is a borderline research language

It's ironic that the "smart" programmers are using their new and novel language to mostly rewrite existing stuff, while the "dumb" programmers were delivering new and novel shit using the "dumb" language.

A higher learning curve brings a better payoff, because where you stop learning is where the language has run out of ways to improve your work.

The higher or lower learning curve for a language has no impact on when you stop learning, only on when you stop learning the language (or making significant gains in learning the language, since there's likely some corner you still don't know or know well).

If you stop learning just because you've mastered a language and learning the language was not your actual goal, you've failed. You should continue learning by applying the language to solve problems, which, unless you solve the same things over and over again, offers plenty of opportunities for continued learning.

Reply on news.ycombinator.com