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

New in Go 1.20: wrapping multiple errors

lukas.zapletalovi.com

Post reply on HN
Print view View original

201–210 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#201

Post by kaba0 »

vlunkr wrote: post #133
imiric wrote: post #27

I guess it's become trendy to hate on Go in this forum, so I'll offer a counterpoint. 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…

The conversation around Go on HN is as broken as a political discussion on Facebook. It’s pathetic.

I think “go haters” bring up plenty of valid points, unlike.. unfortunately any discussion on facebook.

Re: New in Go 1.20: wrapping multiple errors

#202

Post by kaba0 »

nprateem wrote: post #107

I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?

Java with Graal.

Re: New in Go 1.20: wrapping multiple errors

#203

Post by saturn_vk »

divan wrote: post #18
p-e-w wrote: post #3

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)…

> (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone)

Who was the bright spark that decided they the month of all things should go in first? This format makes almost as much sense as Sunday being the first day of the week

Re: New in Go 1.20: wrapping multiple errors

#204

Post by saturn_vk »

shakow wrote: post #42
divan wrote: post #18

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)…

> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for years, and these features still make no sense to me. > lack of enums Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basica…

> Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface.

Language servers are a thing nowadays, and the standard go one will find all implementations before you finish blinking. Why is this considered harder than whatever you are using to find implementations in your language of choice?

> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM.

So like every other language with interfaces then? But why are you even compiling in prod at 3AM in the first place?

Re: New in Go 1.20: wrapping multiple errors

#205

Post by saturn_vk »

za3faran wrote: post #198
727564797069706 wrote: post #120

I once liked Go a lot, then over time got frustrated by few things and moved on. Now I'm all about "Rust is the best thing since sliced bread!" I find it a bit hard to understand why people are critizing Go "yaddayadda oh how wrong this decision is yaddayadda" . Like, who cares. Let them do how they like it. Nobody is forcing anyone to use the language. Go's design decisions are not a universally applicable law or an…

> Nobody is forcing anyone to use the language. Except when your employer does

Nobody is forcing you to choose that employer

Re: New in Go 1.20: wrapping multiple errors

#206

Post by thiht »

sylens wrote: post #4
p-e-w wrote: post #3

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…

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?

> This was a golden opportunity to implement some typical form of exception handling

No one wants that in Go, please stop trying to shove it down like it’s THE solution.

A lot of Go users are fine with the way error currently work, because they’re considered as values, and their handling don’t break the flow like exceptions do.

Sure, Results would have been better, but this ship has sailed. I’d settle for allowing inline « if » expressions, but besides that, error handling in Go is fine.

Re: New in Go 1.20: wrapping multiple errors

#207

Post by foldr »

pjmlp wrote: post #102
switch007 wrote: post #13

Earlier quoted context omitted.

3 second builds?

Yes, thanks to compile on save on IDEs. Also Turbo Pascal, Modula-2, Delphi, VB 6 were already doing that in 1990's hardware. Here Turbo Pascal 5.5 marketing material from 1989, 34 000 lines per minute. https://archive.org/details/TurboPascal55 Go compile times are a reason to admire only for those that never used such compiler toolchains.

I think people are comparing Go’s compile times to the compile times of other languages that they have the option of using in the present day. Go is not the only language in history for which there exists a fast compiler, but its fast compile times are certainly salient when comparing it with a number of popular alternatives. OCaml springs to mind as a plausible alternative to Go that also has a fast compiler, but its ecosystem is vastly smaller.

Re: New in Go 1.20: wrapping multiple errors

#208

Post by hocuspocus »

lokar wrote: post #160
p-e-w wrote: post #3

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…

Go explicitly prioritizes productivity in large Eng orgs with a range of programmer experience. This is often at the expense of what language enthusiasts this is important/new/cool You may not agree, but they are doing what they said they would from the start, and it’s been fairly effective.

Eschewing industry standard ergonomics that have been taught to every developer for the past 3 decades seems like the total opposite of "prioritizing productivity" to me.

Besides, in large engineering organisations you're always going to find multiple languages. Even at Google, which keeps a very short list of blessed languages compared to most companies, the Googlers I know who typically work on "proto to proto" middleware in Go are often jumping into codebases in Java, Kotlin, Dart or TypeScript. So clearly, they can deal with modern language features too.

Re: New in Go 1.20: wrapping multiple errors

#209

Post by divan »

lelanthran wrote: post #68
divan wrote: post #33

Earlier quoted context omitted.

I'm not a member of a Go team. I can comment though as a non-US citizen. This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. Like most of the software historically was born in US, and it's just a very common case where localization is not respected and you see american style dates every now and then. It's getting better, but still, not unusual. While it's different from european…

> This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. I've been using computers since 1986, and I've used many many software packages. Which software package uses month-day-year outside of the US? Every package uses the locale, so the 94% of the population outside of the US literally never sees this format.

Here, quick example from today. Working with an R-script and needed to check date functions [1] and you got mm/dd/yyyy literally in the docs. Good luck figuring out what "%a" or "%D" means, btw.

Another recent example - I had to fight for two hours with yet another javascript date/time picker to present date in localizaiton of a browser. Turns out this popular picker didn't have proper support for localization and set US one by default.

The same issue I had with Flutter time picker, btw. Not sure if it's been fixed by now, but making proper localization support can be quite challenging even in 2022.

Sure, localization support is getting better each decade, but it's far from perfect. And if you've used software since 1986, then you should remember that at that time the concept of localization DIDN'T EVEN EXIST and majority of the software (including DOS!) used US format (there were "localized" versions of DOS, ofc, but those were even branded differently and the best you could get is codepage, keyboard and printer support).

[1] https://www.statmethods.net/input/dates.html

Re: New in Go 1.20: wrapping multiple errors

#210

Post by divan »

masklinn wrote: post #35
divan wrote: post #18

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)…

> Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Very much so. The latter is at least portable between cultures, because a month is a month, unlike "1". And then of course you've got all the collisions like weekday (which for some reason does not follow the US st…

Very much so?

Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.

Post reply on HN