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

161–170 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#161

Post by foldr »

masklinn wrote: post #156
foldr wrote: post #149

Earlier quoted context omitted.

Sarcasm aside, I do think it’s fair to assume that someone writing code in a modern programming language in 2022 has access to basic language-aware editor tooling. That’s the beauty of the language server. You can look up the implementations of an interface from vim, or some other minimalist development environment, if that’s your bag.

"Go is so simple you don't need an IDE to write it, unlike java" "Well obviously you need a proper IDE to protect you from Go's fuckups" Cool.

You don’t need an IDE, as I explained in my two preceding posts in this thread. Please at least try to respond to someone who is actually making the arguments that you take yourself to be refuting.

Re: New in Go 1.20: wrapping multiple errors

#162

Post by richbell »

henry_viii wrote: post #143
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?

I think something like V is what you're looking for: https://vlang.io/

Perhaps V will be suitable for writing production systems one day. Until then, it doesn't seem suitable for anything outside hobby development.

Re: New in Go 1.20: wrapping multiple errors

#163

Post by pjmlp »

cesarb wrote: post #131
ghqst wrote: post #118

Earlier quoted context omitted.

I don't think anyone gets to say that Rust isn't popular anymore. Especially considering it's now in the Linux kernel.

Playing devil's advocate: what's now in the Linux kernel is the infrastructure to allow writing code in Rust, but AFAIK for now nothing uses it (there's Asahi Lina's Rust driver for the Apple M1/M2 GPU, but it's still out-of-tree). I find it likely that Rust in the Linux kernel will not be used for anything important (other than architecture-specific code) until either it can be compiled using GCC (either the GCC bac…

Android fork of Linux kernel uses it. Bluetooth stack was rewritten in Rust for Android 12, and the new virtualization stack in Android 13 is based in crosvm, also a Rust.

Re: New in Go 1.20: wrapping multiple errors

#164

Post by jbboehr »

divan wrote: post #33
Smaug123 wrote: post #30

Earlier quoted context omitted.

Do you have a source for that statement? (For all I know, you are a member of the team who wrote it, so you may know what it means! I certainly had nothing to do with its writing.) 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".

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…

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

Re: New in Go 1.20: wrapping multiple errors

#165

Post by pjmlp »

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 and C# do compile (GraalVM, OpenJ9 do AOT), .NET has NativeAOT, .NET Native, Mono AOT, IL2CPP.

Otherwise, D, Nim, Delphi, FreePascal.

Re: New in Go 1.20: wrapping multiple errors

#166

Post by pjmlp »

gilbetron wrote: post #135
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?

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/

Re: New in Go 1.20: wrapping multiple errors

#167

Post by tialaramex »

lairv wrote: post #124
p-e-w wrote: post #92

Earlier quoted context omitted.

Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.

You are playing with words, Rust / OCaml Option types are effectively the same as nulls in null-safe language, like `string | null` in TypeScript or `string?` in Dart, although I agree it has become necessary for such things to be checked at compile-time

The difference is crucial. With these Sum types a variable of type Option / Dog | null / Dog? might be a dog, but a variable of type Dog is definitely a dog and the language has both of those types.

Languages which just have one nullable type here like Go must use their "might be a dog" type to represent things which definitely are a dog, meaning either you write paranoid checks everywhere or you might screw up - and it's no wonder there are more bugs as a result.

Re: New in Go 1.20: wrapping multiple errors

#168

Post by Smaug123 »

jbboehr wrote: post #164
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…

> 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 anti-American?

But I am one of Those People who goes around $WORK's internal wiki (which has users in the USA and GB) telling people off for failing to use 8601 in their meeting minutes, so perhaps take with a pinch of salt.

Re: New in Go 1.20: wrapping multiple errors

#169

Post by Smaug123 »

fcarraldo wrote: post #153
divan wrote: post #81

Earlier quoted context omitted.

> Your assertions do not make that a reality What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.

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

Re: New in Go 1.20: wrapping multiple errors

#170

Post by 62951413 »

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

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?

The biggest mystery to me is how poorly designed Go is considering its illustrious creators. Thompson and Pike are living legends. They had absolutely nothing left to prove. Yet they came together for another major project, backed by the most powerful technology corporation in the world, and they produced... this? Go feels like a random hodgepodge of ideas from three or four computer science undergraduates – not like…

The parallels to Java are so fascinating on multiple levels. Did you know that Guy Steele was behind it too? At one point it was a revelation to me that the Java designers were not rookies, they just made a conscious decision to dumb things down.

And in hindsight and after 15 years of cleaning up the mess we know that they just needlessly made a generation of developers suffer through primitive abstractions.

Post reply on HN