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

171–180 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#171

Post by fcarraldo »

Smaug123 wrote: post #169
fcarraldo wrote: post #153

Earlier quoted context omitted.

> Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem I mean, you literally got it wrong in this comment, so maybe it’s worth considering whether such a simple mistake might be hard to catch and thus cause real production issues?

(The GP was using the US convention to refer to the two dates 01/02 and 02/01, not trying to use two conventions to refer to a different date each.)

Ah, I see. Apologies to GP, but I believe the point is still reinforced - the biggest enemy of an engineer when it comes to dates is ambiguity.

Re: New in Go 1.20: wrapping multiple errors

#172

Post by pjmlp »

Smaug123 wrote: post #112
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?

… F#? As of .NET 6, ahead-of-time compilation is a thing, and I am led to believe it's got substantially better in .NET 7.

Some correction though.

AOT is already a thing since .NET 1.0, but NGEN has always had the inconvenience of AOT on install with dynamic linking.

WinRT brougth MDIL on Windows 8.x, replaced by .NET Native on Windows 10.

Mono has always had AOT, specially due to Xamarin for Android.

Unity uses AOT for C# code, via translation of IL into C++, IL2CPP.

Currently Native AOT only supports CLI and libraries, .NET 8 hopefully will support GUI applications as well.

Re: New in Go 1.20: wrapping multiple errors

#173

Post by moogly »

divan wrote: post #59
p-e-w wrote: post #37

Earlier quoted context omitted.

> slight inconvenience for non-US citizens So, 96% of the world's population? And even in the US, science and engineering projects commonly use ISO dates. Go's date formatting is as if a random American had taken a quick glance at a paper calendar pinned to the side of their fridge, and decided "yeah, let's do it like that".

Most people can remember "January 2nd" and don't think about US-date vs non-US date.

Well...

January 2nd?

or

January 2?

or

2 January?

Re: New in Go 1.20: wrapping multiple errors

#174

Post by jbboehr »

Smaug123 wrote: post #168
jbboehr wrote: post #164

Earlier quoted context omitted.

> it's definitely not "insane" and not "bizzare". Why would anyone even claim that? Pretty sure it's just anti-American signalling/globalist cultural imperialism. Asian/8601 date format makes a lot more "logical" sense, but nothing beats what you grew up using, at least for me, in a non-technical context.

Obviously your software should present dates in a locale-aware manner, just as it should (where possible) present localised text. But if it's anti-American signalling to expect reference documentation and technical features for non-localised systems (such as the Go programming language) to use the internationally accepted standards for the presentation of non-localised data, then… sure, I guess I'm happy to signal an…

To be clear, I meant it as a general phenomenon and wasn't directed at you. I see a lot of the same thing on reddit, etc. Metric vs imperial is an almost-daily comment chain in the Oxygen Not Included subreddit, for example. It just gets a bit tiring to see the same discussion again and again.

(edit) I'm perfectly fine using 8601 in technical contexts, or anywhere really, but describing American cultural practices as "insane" and "bizarre" is exactly what I'm talking about.

Re: New in Go 1.20: wrapping multiple errors

#175

Post by xanthrax »

tejinderss wrote: post #9
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…

> 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.

set := map[settype]struct{}

This usually covers most cases I've seen for the use of sets

Re: New in Go 1.20: wrapping multiple errors

#176

Post by nprateem »

pjmlp wrote: post #166
gilbetron wrote: post #135

Earlier quoted context omitted.

That's exactly the language I want as well. A mashup of Go and Rust that keeps the best of both. Also, don't forget "compiles fast "! And the garbage collector, although I'd love a language that allowed me to handle memory as well.

Here is one, https://dlang.org/

Thanks for posting this. I've never actually looked at D before but it does seem to tick all the boxes.

Re: New in Go 1.20: wrapping multiple errors

#177

Post by lowmagnet »

nvarsj wrote: post #38

I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute. I feel like a modern language should do either two things with errors: exceptions, or a result monad. Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer.

This functionality is really meant for situations where you do stuff like validate a struct for completeness (part of checking user input, often) and return a list of errors instead of failing at the first error. It's kinda a godsend for the kind of application I write.

Re: New in Go 1.20: wrapping multiple errors

#178

Post by fbdab103 »

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?

Nim [0] feels like it ticks a lot of those boxes. Although it has Options I do not think the machinery is as robust as Rust where that feels like a foundational core of the language.

[0] https://nim-lang.org/

Re: New in Go 1.20: wrapping multiple errors

#179

Post by twsted »

knorker wrote: post #145
twsted wrote: post #97

Earlier quoted context omitted.

> When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. We must live in a different world...

You may not like the language, but it's managed to grow with a consistent story. Yes, there have been some missteps, like auto_ptr and vector , but it does work together. At worst you have to write small adapters because there's no equivalent of smatch for string_view, etc... But compare this to Go, where contexts, error wrapping, generics, uh... error wrapping again (this multierror thing), horrible conditional buil…

I'm saying this after 20 years using C++, from AT&T CFront onwards, all the GotW, years of Boost posts, every Modern, Effective and Exceptional book read. I've loved C++, but now it is complex even with my experience.

Re: New in Go 1.20: wrapping multiple errors

#180

Post by za3faran »

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'll disagree that the compiler is great. Is it fast? Sure, but it produces suboptimal code.

I personally believe that the biggest factor that it became popular was marketing, having well known names behind it both as a corporation, and individuals who had some contributions in Unix land

Post reply on HN