My talk "Go: What we got right, what we got wrong" at GopherConAU is now available to all.
VIdeo: https://www.youtube.com/watch?v=yE5Tpp2BSGw
Blog: https://commandcenter.blogspot.com/2024/01/what-we-got-right-what-we-got-wrong.html
The content is the same except for the Q&A being unique to the video.
@robpike
I'm curious why you don't mention exception handling (or the horrific lack thereof).
That and null safety, more concise lambdas, and parameterized typing from day 1 are why I've shifted my "language of choice for large, GC tolerant projects" to Kotlin in just 2-3 days of Kotlin hacking.
@ncweaver @robpike Use some kind of linter that checks for this.
I mean, this is sort of the equivalent of thinking "this will never fail" and forgetting to use a try/catch in c++; it's not like exceptions necessarily magically eliminate this bug, right? I guess like Java's system sort of forces it, but the linter is the rough equivalent of this.
I'm using exception-free c++ (weird, I know) and https://abseil.io/docs/cpp/guides/status, which IIUC is like Go's error handling, more or less. My environment won't let me compile code if I forget to look at the returned status object. Seems to work pretty well.
@ech @robpike
No, exeptions would fix it because it would have caused an error at that point.
Go's exception handling (or really, criminal lack thereof) is one of the main reasons I decided on not using Go for the class I'm teaching this winter.
The other was the lack of proper type parameterization until just a year ago (which means everything developed before is a right PitA to use).
@ech @robpike
I've specifically been burned by the lack of exceptions the one time I went "this will NEVER fail" and forgot to include the
if err { abort}
That, and map not being thread safe and thread safe map being horribly ugly because type parameterization wasn't in there from the get go.