by jo_beef on 7/18/23, 12:37 PM with 298 comments
by wk_end on 7/18/23, 4:58 PM
This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. Just because Sun couldn't figure out how to do it in the 90s doesn't mean that type inference wasn't mostly solved in the 70s. Well before many people were using it or lived any real length of time, Go's always been a language people have - rightly - complained about.
That said...nothing in the original post says anything along the lines of "Go's type inference [is] an advance in the state of the art", so I might be misunderstanding the author here.
by iamcalledrob on 7/18/23, 4:49 PM
The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is chefs kiss.
Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the type system and the way everything's constantly deprecated.
It's not all perfect. I wish the generated binaries were smaller. I wish the protobuf library wasn't awful. And better Cgo/FFI would be nice.
But overall, I've never been so productive.
by bborud on 7/18/23, 4:47 PM
My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now.
I want to make stuff and not endure people boring me with this weeks clever language hack they came up with that expresses in one unreadable line what could have been expressed clearly in 3 lines.
by j1elo on 7/18/23, 5:39 PM
Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I had to worry about 8 lines with stuff that had become unused. The stubbornness about not adding an escape hatch for, again, exploratory intermediate development iterations is unnerving.
"But code should not leave unused stuff around". I agree. That's why after a hundred iterations, in the final compilation phase for production, this kind of errors-are-warnings flag would be disabled.
by vl on 7/18/23, 7:01 PM
Verbosity of error handling!
There should be a shorthand for returning if last ret value is non-nil in one line. Otherwise all you code is littered with:
if err != nil {
return err
}
Also, go fmt is not opinionated enough! There really should be one way to line break and max width. Right now you can't rely on it to magically format it as it "should be" and fire-and-forget when typing.
by crop_rotation on 7/18/23, 4:00 PM
by stpedgwdgfhgdd on 7/18/23, 4:31 PM
What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.
by stevemk14ebr on 7/18/23, 6:34 PM
I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do this in a non-manual fashion you're required to parse all of the code exactly perfectly (ASTs and such). Even go itself has not figured out how to do this, rf is still experimental and not complete: https://pkg.go.dev/rsc.io/rf.
Example use case: https://github.com/golang/go/issues/46792
I much prefer the non-viral public/private attributes other languages use.
by wolfspaw on 7/18/23, 4:32 PM
I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures.
Now it has Generics, soft RT GC, and it might even get official Arena Allocation.
I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.
by kubb on 7/18/23, 3:43 PM
As for the success, it's obviously the minimal set of language features, conformance to established paradigms, not being very broken and being backed by Google.
There's a ton of suboptimal choices in Go, but overall it can work for many applications.
by veber-alex on 7/18/23, 4:08 PM
In Go the type system doesn't force you to check for errors, the same way as languages with null pointers don't force you to check pointers before dereferencing them.
That's the real problem with errors and null in Go, not the verbosity (though that doesn't help)
by tail_exchange on 7/18/23, 4:16 PM
Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not something that can be changed now without breaking backwards compatibility.
by synergy20 on 7/18/23, 4:43 PM
I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot.
On the desktop side, I really hope Go can have a GUI in its stdlib, something like what Flutter/Dart does: adding a Skia kind of engine and let me do GUI cross platform, that will make Go main stream like wild fire.
by whimsicalism on 7/18/23, 4:06 PM
by Veraticus on 7/18/23, 4:11 PM
As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic.
I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functions. Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.
Anyway. This was a good initial post and a good follow-up. Go is my favorite language out there right now for its clarity, power, and ease-of-use. And with loop variable capture coming (the biggest remaining foot gun in the language in my experience) the language is only getting better.
by seeknotfind on 7/18/23, 3:39 PM
by anonyfox on 7/18/23, 6:21 PM
Go: amazing tooling/libs, only needs a great language :-)
But a few tweaks, like proper Enums and a Option/Return Type (to avoid excessive err != nil), maybe a compilerflag to force dealing with errors (instead of _ it) - much better. If I can wish for something, then some native map/filter/reduce to avoid excessive for-loops…? :-)
by mrbonner on 7/19/23, 3:17 PM
by aptenoforst on 7/18/23, 5:49 PM
I wish there was something like Go but with an actually good programming language attached.
by worik on 7/18/23, 8:06 PM
I need some resources for evangelizing GO.
I do not use it, but...
I have a colleague who needs/wants to replace a PHP/Laravel mess. They are talking up Node.js
I think GO would be a better choice
This article is close to what I need, but is there anything better?
The server side code they are looking to replace is handling sensitive financial information and I am very queasy using Node.js in that domain
by Alifatisk on 7/19/23, 1:52 PM
- Simple
- Highly concurrent
- Impressive networking stdlibs