Hacker News Reader

Comment by kccqzy | Hacker News Reader

> You can put junior programmers on something and they'll probably get it more or less right.

I see junior programmers screw up Go catastrophically. Thinking green threads are magical, they forget the existence of mutexes and the resulting code has data races left and right. Languages like Haskell combine green threads with carefully controlled mutation (be it IORef or STM) to avoid this. Go doesn't, so you still need low-level knowledge like how to avoid deadlocks.

As I've said before, Go gives you the veneer of an easy language when it's in fact full of traps for those who aren't experts.

View on HN

Most companies, in my experience, want tools that are easy to get right in 80% of cases, and in 20% of cases require experts. Go has the benefit of most benign work is deadass simple to get right. The things you referenced in your post are obviously the remaining 20%.

Rust, as an example, is a pretty difficult language to become productive in. Sure, once you've invested the time, you're equipped to handle a wider array of problems, but most organizations don't particularly care about the top. They care about becoming relatively productive relatively quickly.

Go's approach to certain problems require expertise, it is not a silver bullet. But there are no silver bullets, and the examples you gave require expertise in any language. The issue is that you've kind of just cherry picked those three concepts as proof of complexity, ignoring the boatloads of other examples in which Go's simplicity does add value.

> Rust, as an example, is a pretty difficult language to become productive in.

Perhaps it's experience with other languages, or the fact that I grew up when that sentence started with C++, but I honestly found rust pretty easy to get up to speed in.

Am I an expert? No, and until I get the chance to use it for a living that won't change. But getting from "I want to do X and Y with this language" to having done so was straightforward enough.

I'm happy that you became productive in Rust quickly; I do not believe that to be the average case.

On the average Rust is quite difficult. And if you're someone doing a side project or trying to build a startup I wouldn't advice using Rust initially

Stripping a language down to the point we can learn it in a week is a bad tradeoff, because we'll never improve after that. The toolbox will always be empty, best treated as a codegen target for abstractions in some more insightful language.

There are plenty of languages that you can go from "Never touched" to "Having contributed something" in a week. Are you saying that those languages aren't productive or valuable?

A language is productive if it reduces the effort to solve your problems. I think some people feel productive as soon as they're able to solve a problem by cranking out a lot of code, but I view that as the language failing to help them.

Best of luck.

Totally agree. I never understood as a demerit that go is boring ... like it's some slight to programmer swagger. Most engineers prefer simple. Beginner programmers may screw up go but in my experience it's more a limited gestalt issue: they can't wrangle the requirements, the domain types, code structure (and whether those are in shape or no) ... Consequently they react to the code in terms of how it comes to them.

> I see junior programmers screw up Go catastrophically. Thinking green threads are magical, they forget the existence of mutexes and the resulting code has data races left and right....

When I worked at a company that used Go, I saw senior programmers with decades of C++ experience screw Go up in exactly this way.

That's exactly what I meant. C++ is a hard language and it doesn't pretend it's easy. Go is also somewhat hard but it really pretends it's easy.

Go is comparatively easy. However, if you think it is very easy, it is very probably that you will make many mistakes in using Go.

I have said it many times: Thinking Go is easy to master is considered harmful. Holding such opinion (thinking Go is easy to master) will make you understand Go shallowly and do many mistakes in Go. One the other hand, if you learn Go seriously, Go could help avoid these mistakes easily (and with a happy programming experience).

I see this in Elixir all the time too. Lots of people seem to think that immutability combined with message passing makes their program immune to races. As a consequence I see all sorts of designs with races all over the place.

Indeed there's a discussion of this in the official Elixir site's Getting Started guide:

https://elixir-lang.org/getting-started/mix-otp/ets.html#rac...

Yes. Go's locking is really no better than C/C++. There are queues, and there are mutexes. Everybody has those now. Go just has a new story for them. The whole "share by communicating" thing tends to lead to people just putting "tokens" on queues, not the actual data.

But Go does have a run-time race condition checker.

Yes, in retrospect Go's push to "make concurrency easy" ended up being one of its worst attributes; Go's real value is in its simplicity, efficiency, and boringness, all of which concurrency runs counter to. On the other hand, it's questionable whether Go would be as popular as it is today if it hadn't hyped up the concurrency angle.

"it's in fact full of traps for those who aren't experts." This is true for pretty much every languages.

> "it's in fact full of traps for those who aren't experts." This is true for pretty much every languages.

Yes, but every language has a different number of traps, and each trap has a different difficulty, and each person has a different likelihood of encountering each trap.

So when someone says that, they mean that it's worse than the average (well known) language on one or more of those axes.

well, Go is definitely not worse than average in this regard.

Mutable parallelism is indeed hard, but you don’t have to be an expert to know the basic rules (lock mutable things) and design your application to minimize concurrent mutation. By contrast, learning Haskell well enough to be productive takes weeks if not months. As for Haskell, it sure addresses parallelism, but it introduces far more significant problems with respect to application development. There are reasons it isn’t widely used in production.

I learned three new terms today.

Green threads, data races, mutexes.

This is true of every language.

Reply on news.ycombinator.com