21–30 of 243 posts
The more Go evolves, the more clear it gets that it has a very poorly designed foundation.
I say that as someone who's coded and reviewed a lot of Go code.
Maybe they should not have skipped 40 years of language theory when first creating it. It wasn't obvious in the beginning, but now...
Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…
> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…
> It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day.
Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use.
(I mean, in what world is it even remotely memorable that the canonical order is month, day, hour, minute, second, year, timezone? That decision is just… really bad!)
Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…
Isn't this line of argument somewhat self-defeating? It sounds as if these language design decisions that cause a vocal minority to complain loudly have only a marginal impact on actual productivity (or at least the perception of it). If so, that would be quite a good justification for not complicating the language by, e.g., adding enums, a non-nil pointer type, etc. etc.
Earlier quoted context omitted.
> everything from TLS to CSV is rolled into std without ever having to import a third-party repository And yet the std library is missing some basic data structures like Set.
Because they can't be properly implemented without generics, and generics were only shoehorned into Go a decade after its initial release.
If they wanted a set data structure they could have had it like they do maps and slices.
Earlier quoted context omitted.
> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…
The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time : > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it…
Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
Earlier quoted context omitted.
I’m glad it’s not just me who is perplexed at some of the decisions made with golang. This was a golden opportunity to implement some typical form of exception handling. Instead you have to bundle your errors together and then unwrap them (often using multiple methods to handle the cases of both a single error and a bundle of errors) and then still implement even more logic to walk the tree you made?
Exception handling sucks, stop asking for it. Did you worked in Java? Did you worked with async and exceptions?
And golang has them in the form of panics and they suck in goroutines.
Being a relative newcomer to the language, transitioning from Python circa 2016, I've found it a joy to use. The simplicity of the spec, the true "one way to do it" philosophy, the way it forces you to simplify and avoid cleverness (yes, sometimes at the expense of verbosity, which only makes things clearer, and rarely tedious), the great crossplatform support, stdlib, and tooling around it, and many more features, have made it my favorite language.
Yes, there are still some warts and odd design decisions, but those are far outnumbered by the good things about it. Most of the issues are related to Go's team unwavering dedication to backwards compatibility, which is respectable. The fact we got generics in v1 is incredible. I can't wait for what v2 will bring, without the shackles of backwards compatibility.
This errors feature in 1.20 is neat, but I'm much more excited for context cancellation reasons[1], which will hopefully be released soon as well. That should greatly simplify debugging, and avoid the common generic "context canceled" errors.
Earlier quoted context omitted.
Something about needing to use fmt.Errorf to JOIN errors if you want custom string formatting rubs me the wrong way. I had to read that section twice because it completely went over my head it acting as a join.. So unexpected for fmt to be doing error biz like that.
Especially given the current landscape of log handling as the author points out. I am all in on structured logging most of the time and I don't want to have to deal with a newline causing multiple records in my log aggregation.
Yeah, it's not exported but...
Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…
> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…
Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much less popular.
Earlier quoted context omitted.
The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time : > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it…
This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
To me, the statement is obviously saying "yeah this order is just bizarre, why on earth did we put the two most significant digits around the outside of the rest, good luck".