New in Go 1.20: wrapping multiple errors • Hacker News Board

Re: New in Go 1.20: wrapping multiple errors

#111

Post by cube2222 » Sun, Dec 11, 2022, 2:52 PM UTC

shakow wrote: post #90

cube2222 wrote: post #66

Earlier quoted context omitted.

> 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. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package…

> The language has static type-checking. No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. > Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". Does not work all the time, hence my use of the ‶rickety″ adjective. > This makes understanding what a piece of code is…

> That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them.

It really isn't. This way it becomes a guessing game "Which methods will be used with which other ones?".

Even if I have a KVStore interface with 4 methods: Get, Set, List and Delete, it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete.

The other commenter already responded to your static typing assertion, so leaving that for there (it absolutely does check it).

Re: New in Go 1.20: wrapping multiple errors

#112

Post by Smaug123 » Sun, Dec 11, 2022, 2:53 PM UTC

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.

Re: New in Go 1.20: wrapping multiple errors

#113

Post by cube2222 » Sun, Dec 11, 2022, 2:53 PM UTC

pjmlp wrote: post #88

cube2222 wrote: post #66

Earlier quoted context omitted.

> 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. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package…

> Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". And me thinking the Go culture is against languages that tend to come with IDEs...

Go culture, like any other, is diverse.

I prefer to use an editor/IDE and don't think it's pleasant to work with any language (including Go) without them.

Re: New in Go 1.20: wrapping multiple errors

#114

Post by cube2222 » Sun, Dec 11, 2022, 2:57 PM UTC

Smaug123 wrote: post #108

cube2222 wrote: post #75

Earlier quoted context omitted.

That is a fair point and it's why I use errcheck[0]. [0]: https://github.com/kisielk/errcheck

Magic! I just checked, and this found the bug in a Go tool I use that bit me a couple of months ago, which I'm still smarting from. Thanks!

Glad I could help!

In general, I recommend using golangci-lint[0], which aggregates a ton of useful linters like this one.

[0]: https://github.com/golangci/golangci-lint

Re: New in Go 1.20: wrapping multiple errors

#115

Post by kaba0 » Sun, Dec 11, 2022, 2:59 PM UTC

p-e-w wrote: post #14

kaba0 wrote: post #10

Earlier quoted context omitted.

For all that you have the JVM ecosystem with multiple better languages (including Java itself)

I would hesitate to call Java a better language than Go, but Java is much older so the designers of Go should have learned from Java's mistakes, which they did not. When Java was new, though, it was certainly a far better language compared to its contemporaries than Go was when it came out in 2009.

Its exceptions (even with the not perfect checked ones) are eons better than Go’s solution. Not sure how expressive Go has gotten with generics, but Java can solve plenty of problems very elegantly with streams. Oh, and did I mention that Java is goddamn more concise than Go? But for some reason verboseness is never brought up against the latter.

Re: New in Go 1.20: wrapping multiple errors

#116

Post by hocuspocus » Sun, Dec 11, 2022, 2:59 PM UTC

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?

Swift?

Maybe Carbon eventually.

Re: New in Go 1.20: wrapping multiple errors

#117

Post by grose » Sun, Dec 11, 2022, 3:00 PM UTC

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?

Zig? I think it ticks all the boxes.

Re: New in Go 1.20: wrapping multiple errors

#118

Post by ghqst » Sun, Dec 11, 2022, 3:03 PM UTC

lelanthran wrote: post #100

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.

> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…

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

Re: New in Go 1.20: wrapping multiple errors

#119

Post by shakow » Sun, Dec 11, 2022, 3:03 PM UTC

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?

Kotlin Native?

Re: New in Go 1.20: wrapping multiple errors

#120

Post by 727564797069706 » Sun, Dec 11, 2022, 3:07 PM UTC

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 anything that you must follow even if you don't like them. I mean, if you're using the language and dislike this decision, then it's a bit different story and I think you should influence the change through the official channels. Probably you've done it already.

Fact of the matter is that there are TONS of people out there (and here too) who agree with those decisions, keep using the language and enjoy it. And for that I'm happy for Go!