Comment by KirinDave | Hacker News Reader

Comment by KirinDave | Hacker News Reader

Parent Full thread

Do you really think Go is that good? I look at it as a very awkward language in many ways.

1. Go's got just... broken error handling. Please write a dozen if (err != nil) gates in a row and try not to mess up.

2. Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it.

3. #2 may be a blessing in disguise because working with large single-delivery channel pipelinesis actually quite awkward. Our normal go-to techniques of exception handling and trace debugging don't handle it well outside of very small contexts. 40 years of debuggers all focus on the call stack and Go smashes that.

4. Go's quite convenient for a small team banging out software but for a large team over a long period of time, we still don't have access to the versioning and build systems Google had that make a lack of good version control feasible.

5. Despite being a language all about I/O, Go brings no real new innovations in I/O to the table.

6. Go's developer mantra is at least as patronizing as Python's. Probably more so.

Go's kafkaesque error handling made me loathe writing code. No language has ever done that.

> Do you really think Go is that good?

Its not that good yet. It doesn't even have the capacity to replace my Python usage yet. What I miss is the community driven libraries/packages - including sci-computing libs. If Golang is supported in browser, things could change for it quickly.

Its not the stuff like error handling that irks me - atleast not in comparison to JS callbacks and promises. I think the error handling is necessary. In Go, you could always ignore errors with underscores. But then ignoring errors works great until it doesn't. :)

However, we want to bring something better to the web not something that is detrimental in hopes that thing itself becomes better.

Go is not a good fit.

> Go's principle concurrency primitive, channels, is actually very slow as per its implementation and is often avoided because of it.

I've only heard the opposite about it (only used Go on hobby project, so no first-hand knowledge). Can you please elaborate or give some links that discuss it?

> Go's developer mantra is at least as patronizing as Python's. Probably more so.

Are you referring to limiting developer's freedom?

Well channels use mutexes underneath and they are "slow". So slow in this case is very relative.

Go channels are slower than go mutexes for the same task set. See: http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...

They don't need to be. But using channels for message passing instead of actors makes performance difficult.

> 6. Go's developer mantra is at least as patronizing as Python's. Probably more so.

What do you mean by that?

One of Go's design principles is that "we're full of untalented junior programmers who wouldn't know what to do with fancy techniques anyways."

Sort of like Python's multi-decade insistence that Lambdas confuse people despite the fact that it's standard after massive popular demand even in Java.

It's quite insulting, if you ask me. Sort of like an elder telling a teen the power tools are off limits because they are "only 16 and not coordinated enough yet to use the table saw without losing a finger."

I would also like to know.

Reply on news.ycombinator.com