Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thirteen Years of Go

go.dev

Post reply on HN
Print view View original

181–190 of 217 posts

Re: Thirteen Years of Go

#181

Post by kaba0 »

doorman2 wrote: post #141
kaba0 wrote: post #137

Earlier quoted context omitted.

What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development. 1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast. 2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Genera…

1) It has okay speed. Also, the GC is a very naive one, not “good” compared to other managed languages.

3) Besides C#, which languages doesn’t have typed erases generics? Most languages implement it through erasure. Also, Go’s generics are basic as hell..

4) Not sure about write, read.. deeply nested for loops, error handling taking up place everywhere, literally more verbose than even Java

5) it has plenty of hard-coded shit already, due to missing generics for a huge time (e.g. built-in data types)

Javascript is quite performant, but I have to agree on concurrency.

JVM languages: I don’t think it has bad tooling at all, and it is fucking performant (with much better GCs).

Re: Thirteen Years of Go

#182

Post by flippinburgers »

kaba0 wrote: post #128
Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.

It is good to be forced to recognize errors and manually send them up the stack. Too many programmers have a "not my problem" attitude about errors.

1. Immediately when the error occurs, send it to logging with all required data to find the exact point of failure + data to understand the "why".

2. Send the error up the stack.

If you do these two things, your systems written in golang will be resilient.

Re: Thirteen Years of Go

#183

Post by flippinburgers »

playingalong wrote: post #160

Anyone else feeling put off by golang? The syntax, the crazy error handling, etc. To me it's like taking a step back in programming, or actually 20 years back. Not better than Java (which is annoyingly verbose), maybe better than Pascal.

Error handling at worst is an annoyance. The syntax? You will get used to it. Everyone has to adjust to every syntax whenever they learn a new language whether they realize they are or not.

Re: Thirteen Years of Go

#184

Post by kaba0 »

flippinburgers wrote: post #182
kaba0 wrote: post #128

Earlier quoted context omitted.

Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.

It is good to be forced to recognize errors and manually send them up the stack. Too many programmers have a "not my problem" attitude about errors. 1. Immediately when the error occurs, send it to logging with all required data to find the exact point of failure + data to understand the "why". 2. Send the error up the stack. If you do these two things, your systems written in golang will be resilient.

So rely on the programmer countering their laziness instead of having these things the default in the language also known as exceptions?

Re: Thirteen Years of Go

#185

Post by Ferret7446 »

Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Many of those things are a consequence of the language, or at least the philosophy behind the language.

e.g., tooling is good because the language is easy to parse

Re: Thirteen Years of Go

#186

Post by kaba0 »

Xeoncross wrote: post #179
kaba0 wrote: post #173

Earlier quoted context omitted.

You surely know that it is very common to rethrow the original exception wrapped in languages with try-catch — it still saves you the time to write that (plus it is safe, no code, plus stacktrace). It is still strictly better than whatever go has.

I've written a lot of try/catch but no one in those languages do that for every branch, it's usually just everything wrapped in a big try/catch. Go makes you deal with the error every single time something could go wrong, so you have a chance to do the right thing and append context at every single failure path.

Go makes you believe you dealt with the error, but instead you just forget about it.

Also, checked exceptions are very much not like that, and being able to handle errors of a logical unit is also beneficiary (e.g. transactions). You are free to use the scope-size that makes sense for the given use case.

Re: Thirteen Years of Go

#187

Post by smasher164 »

kaba0 wrote: post #172
smasher164 wrote: post #135

Earlier quoted context omitted.

> A pragmatic “handle it here or bubble it up” is a much better approach This is exactly the approach used in Go code, so I'm not sure what you're referring to. If you're talking about the fact that you can technically ignore an error result like res, _ := doWork() then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 for that.

I don’t see any automatic bubble up with Go.

I don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler.

Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.

Re: Thirteen Years of Go

#188

Post by icedchai »

playingalong wrote: post #160

Anyone else feeling put off by golang? The syntax, the crazy error handling, etc. To me it's like taking a step back in programming, or actually 20 years back. Not better than Java (which is annoyingly verbose), maybe better than Pascal.

I like Go's tooling, but I am consistently put off by the language. It's best described as "meh."

Re: Thirteen Years of Go

#189

Post by mahogany »

valenterry wrote: post #87
rob74 wrote: post #60

Earlier quoted context omitted.

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. Ok, I get it that there are developers that can't live with languages that don't have tons of shiny features to play with, but please don't disparage the others as "inexperienced"! If you have ever gone back to some "expressive" code you wrote months…

It's not "shiny features". It's things that can make you more productive. Or would you say golang's channls are also a shiny feature? Also, I'm not "disparaging" anyone here. Please read it again and notice that I was simply saying that golang is good if you are inexperienced. That does not mean that every golang dev is inexperienced. If you interpreted my post in that way, I think you should probably ask yourself wh…

But you said:

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.

which implies that people who use Go have not grown and become as productive as people that use more expressive languages (because such languages are a "must" to grow in this way). At the very least, you are obviously disparaging Go programmers' productivity.

Re: Thirteen Years of Go

#190

Post by ColonelPhantom »

tptacek wrote: post #163
masklinn wrote: post #155

Earlier quoted context omitted.

> I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. Are you saying that you’ve had 5 bugs caused by unnecessary imports ?

I'm saying I've had that stupid import error pop up in my face 5 times and changed my code as a result, rather than the imports, because it surfaced an error.

Shouldn't it be a warning, though? You'll still notice it, but you aren't forced to deal with the problem immediately.
Post reply on HN