Ten years of “Go: The good, the bad, and the meh”
blog.carlmjohnson.net
Ten years of “Go: The good, the bad, and the meh”
1–10 of 305 posts
Re: Ten years of “Go: The good, the bad, and the meh”
#2[deleted]
Re: Ten years of “Go: The good, the bad, and the meh”
#3Great article. Go may have generics, but because old Go code doesn't, and the standard library doesn't, it still feels like the language doesn't sometimes.
Re: Ten years of “Go: The good, the bad, and the meh”
#4Copilot and the like are good for Go, because you can generate all the boilerplate code they make you write.
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.
Re: Ten years of “Go: The good, the bad, and the meh”
#5Great article. Go may have generics, but because old Go code doesn't, and the standard library doesn't, it still feels like the language doesn't sometimes.
Basically learning the lessons of Java and C# all over again. Yes, there are features you can defer implementing until later, but their absence infects everything until you do. I still see cases where people have to drop down into ADO.Net code for C#, and the fact that you still see DBNull.Value instead of just a simple null value, much less a proper Option type is infuriating.
Like I write a lot of Powershell code and their stuff still returns DBNull.Value when returning a null value from the DB, when nullable value-types were introduced almost 20 years ago.
Re: Ten years of “Go: The good, the bad, and the meh”
#6Great article. Go may have generics, but because old Go code doesn't, and the standard library doesn't, it still feels like the language doesn't sometimes.
Basically learning the lessons of Java and C# all over again. Yes, there are features you can defer implementing until later, but their absence infects everything until you do. I still see cases where people have to drop down into ADO.Net code for C#, and the fact that you still see DBNull.Value instead of just a simple null value, much less a proper Option type is infuriating. Like I write a lot of Powershell code a…
The documentation for DBNull [1] seems to have some idea that DBNull represents something entirely different.
> Do not confuse the notion of null in an object-oriented programming language with a DBNull object. In an object-oriented programming language, null means the absence of a reference to an object. DBNull represents an uninitialized variant or nonexistent database column.
For all the explanation though, I couldn't fathom what its talking about.
[1]: https://learn.microsoft.com/en-us/dotnet/api/system.dbnull?v...
Re: Ten years of “Go: The good, the bad, and the meh”
#7The stdlib is the killer feature of go. Several times I wrote high enough performance small services/servers that people not familiar with go were astounded with (mostly the speed of writing the code and memory usage). I made many go converts this way. And I always only had to use the stdlib (many benefits when writing within a company).
Re: Ten years of “Go: The good, the bad, and the meh”
#8Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.
Re: Ten years of “Go: The good, the bad, and the meh”
#9> Go’s error handling is more verbose than those other languages, but structurally, there’s a lot of commonality under the surface.
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)
Re: Ten years of “Go: The good, the bad, and the meh”
#10Very insightful. Re: the generics point —
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.