Hacker News Reader

Comment by zozbot234 | Hacker News Reader

It's a bit weird to see "several weeks" of effort being described as a problematic learning curve. At least the blogpost makes it clear that the effort pays out hugely but still, "several weeks" is not rocket surgery. It's not learning Haskell or category theory! ISTM that they're just running with an assumption that most devs wouldn't be professional and committed to this, which strikes me as an unwitting gatekeeping attitude.

View on HN

Go has a shorter time, and that’s the measuring stick in this area.

Go appears to have a shorter time, because you don't realize how much higher-level stuff you're just expected to do The Right Way, with no support from the language or libraries. So you're free to think you've finished learning Go, but then the actual learning begins.

"The Right Way" lies in a wide spectrum and depends on the project.

It's often about how fast one can deliver maintainable software that works well enough.

Right, it's a false economy. Though, to be fair, the Java/C# ecosystem has the same problem to an even greater degree. Not to mention popular "dynamic" languages such as Python, Ruby etc.

Even accounting for what you say, it's a short learning curve compared to most languages. It's not like there's any programming language in the world where you just read the manual through once and, boom, instantly you know exactly how to architect a multi-person-century project right out of the gate or something.

Hmm, that’s a bit of a straw man you’re making here. No one is arguing better languages will magic complex architecture efforts, we’re talking about basic state management here... garden variety implementation details

State in the context of concurrent programming is not a "garden variety implementation detail." It's the Great White Whale of our industry. No language does it especially well. I have my favorites in this arena, but it's still hunting a large sea mammal with a harpoon. What you're suggesting is essentially avoiding hunting it altogether. We're not there yet.

Agreed. Worked with a senior who "learned go in a week" then faffed around for months (to prod! because he had the implicit trust of management because he was "a genius") deploying broken software with tons of concurrency bugs because he didn't know how to manage shared state.

This is very true. I recently ported large portions of Go code to Rust, and while it was somewhat of a steep learning curve and a fight with the compiler, in the end I felt very comfortable that the result is correct, fast, and had good abstractions.

Go was so "easy" that I was immediately productive, but this resulted in often suboptimal and messy code that I had to refactor over and over again due to concurrency, abstraction, or performance issues.

True productivity is hard to measure.

Learning should pay off. Bragging that one can learn your language quickly is like bragging that your toolbox is nearly empty.

Go is the golden standard for extracting the most value out of unexperienced computer science grads but it is not the measuring stick, not by a long shot.

Java did it first, catching up with 1996 here.

Interestingly enough, Java caught hell from people for "pandering" to "average" programmers, where Go seems to be getting kudos for the same thing. Strange times.

I've only ever read through Go tutorials but never used it. I've used Java in a small capacity, and while I found some things convenient, some other things were also pointlessly restrictive. For example that syntactic overhead, having to wrap everything in a class. You can't even have a global variable without typing your fingers sore.

Pretty sure that Go isn't equally restrictive (while still being garbage collected).

Java was derided as being for people who thought C++ was too hard. But those people were right. C++ is too hard, in that "undefined behavior" demands an inhuman degree of perfection.

And now Go is being praised for being for people that think Java and Python are too hard.

It is a better option than keeping using C, and it would have been great in 1996, but that is about it.

Learning a new framework in a familiar language might take a few weeks. A few weeks for a new language is really fast!

But with rust you have to re-learn the language every six weeks as it changes so fast. (/s)

I think learning Rust will be harder than Haskell for a lot of people.

Hmm I don't think so. Haskell is so fundamentally different to imperative languages that it requires basically throwing away everything you know about programming.

To learn Rust you simply need to understand how values are kept track of by the compiler. Once you develop an intuition for this it's the same as any other modern imperative programming language.

I have learned both and agree with this statement. I think that Rust is harder to learn if you've only worked with high-level, GC languages, and don't have a background doing lower-level programming in C/C++/Obj-C, as well as some experience with functional languages.

Going from something like Java or Python to Rust, one would have a lot to learn.

Reply on news.ycombinator.com