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

Go 1.13: xerrors

crawshaw.io

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Go 1.13: xerrors

#71

Post by takeda »

AsyncAwait wrote: post #59
apta wrote: post #45

Earlier quoted context omitted.

That's a stawman fallacy. There is no perfect language. However, there are languages that almost are strictly superior to others. Java and C# in this case are almost strictly superior to golang in almost every front.

Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others.

I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1].

Perhaps I'll upset some, but IMO Go would be another obscure language that no one cared about if it didn't come from Google.

[1] https://kolibrios.org/en/

Re: Go 1.13: xerrors

#72

Post by whateveracct »

icholy wrote: post #14
trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

> I use this language extensively but its weirdly mediocre design is totally unfathomable. So then why do you use it extensively?

I mostly write Haskell professionally, but I still reach for Go depending on the project. Sometimes it just has the libraries I need and I can tell up front that I'm willing to deal with the tedium the language forces on me. Cost/benefit analysis.

Re: Go 1.13: xerrors

#73

Post by cle »

apta wrote: post #51
cle wrote: post #42

Earlier quoted context omitted.

Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Re: exceptions, there are a lot of people, myself included, who do not view exceptions as "advancements", but as setbacks. Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go) is an awful way to do error handling, and you end up having to…

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as wel…

> Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as well as correctness. People should just face the fact that returning errors as a product type is a mistake.

These are still essentially the same. Errors are returned as values, with no major difference in runtime semantics. Whether the language supports union types is orthogonal to that.

> You may want to see what approaches Akka or Erlang takes here. golang authors just decided to ignore established practices and use clunky approaches to problems that have already been solved.

There's not one solution, there are multiple solutions with various tradeoffs. The tradeoffs Go made are congruent with its tenets as a language that values simplicity and low cognitive overhead.

Re: Go 1.13: xerrors

#74

Post by tylerhou »

cle wrote: post #42
tylerhou wrote: post #39

Earlier quoted context omitted.

I assume exceptions, the Error/Either monad, and StatusOr.

Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Re: exceptions, there are a lot of people, myself included, who do not view exceptions as "advancements", but as setbacks. Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go) is an awful way to do error handling, and you end up having to…

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values).

Not really, it's very annoying to chain calls which can error. Also, as another commenter mentioned, functions which can potentially fail should return sum types and not product types.

Compare:

    do first
and

    first, err := computeFirst()
    if err != nil {
        return nil, err
    }
    second, err := computeSecond()
    if err != nil {
        return nil, err
    }
    return f(first, second), nil
Even without do-notation the Haskell is considerably shorter:

    computeFirst >>= (\first ->
    computeSecond >>= (\second ->
        return $ f first second))
Agreed about exceptions, though; I dislike them as well.

Re: Go 1.13: xerrors

#75

Post by apta »

lmkg wrote: post #69
apta wrote: post #53

Earlier quoted context omitted.

One reason perhaps is that TypeScript took over that space, and TypeScript also came from a well known company.

And, like Go, TypeScript was strongly associated with a lead designer whose name is well-known and who shaped the industry over multiple decades.

Except that TypeScript's designer had strong and established experience in language design, and he made a lot of correct choices when implementing TypeScript. Can't say that about golang.

Re: Go 1.13: xerrors

#76

Post by apta »

cle wrote: post #73
apta wrote: post #51

Earlier quoted context omitted.

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as wel…

> Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as well as correctness. People should just face the fact that returning errors as a product type is a mis…

> These are still essentially the same. Errors are returned as values, with no major difference in runtime semantics. Whether the language supports union types is orthogonal to that.

It's not just about runtime semantics. If it were, then exceptions should perform better than returned error values in the non-error case (which should be the majority of the time anyway). It's also about how code gets written, and more importantly, how code is read.

> There's not one solution, there are multiple solutions with various tradeoffs. The tradeoffs Go made are congruent with its tenets as a language that values simplicity and low cognitive overhead.

Which in practice, doesn't really show. Simplicity at the language level manifests as longer, more complicated code in real designs, because real life is complicated. It's pushing the load from the language and compiler implementors on to the end user.

Re: Go 1.13: xerrors

#77

Post by alexbanks »

grey-area wrote: post #55
trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

So what would you do then? If you don't like it, don't present pale echoes of criticisms we've already seen (not listening to 30 years of language design...), tell us what you would do instead, because the answer is non-obvious and there is no one 'right thing'.

What a ridiculous way to think about language design. The users of a language are best suited to define what parts of the language do not feel good to them - why are they expected to come up with solutions for the language designers? In your mind, are you only allowed to present criticism if you're also able to define solutions? Doesn't that limit the people that are allowed to criticize to the language designers themselves? That seems like an excellent way to get tools nobody wanted, no?

Re: Go 1.13: xerrors

#78

Post by apta »

Thaxll wrote: post #68
apta wrote: post #63

Earlier quoted context omitted.

Compiling to a native binary is not a strict advantage, there are many advantages for running in a managed environment, and it can be argued that for critical systems it is the superior route in fact (given that you have the resources to run said VMs, which unless you're doing embedded or resource constrained systems, is a non-issue). That being said, both Java and C# can compile to native binaries. Java is getting F…

- simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring ) - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server. - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch ) - Don't need 2…

> - simplicity, never worked on those projects using layers of layers with a lot of magic ( like Spring )

Another strawman. There are many other frameworks other than Spring that are simple and performant and easy to deal with.

> - memory consumption, never wondered why you never see Kubernetes sidecar / daemonset in Java / C#? because they use 5-10x the Go memory, no thank you using -xmx -xms 512MB for a simple API server.

No one is requiring you to use -Xmx 512MB. The JVM will take up as much memory as you give it. And newer GCs will release unnused memory back to the OS much more aggressively.

> - the billions GC settings that you need to try to make something work at scale ( hello Elasticsearch )

golang barely has any settings, which completely limits how it can be used. If you want to tune your code for throughput instead of latency, well you can't. The JVM gives you this option, and even moreso with ZGC and Shanendoah (TBs of heaps with ~1ms max latency). golang's gc can't even approach that.

> - Don't need 200MB of library to open a file or create a REST server

That's quite ridiculous. You don't even need any dependencies to open a file. And not all JVM web frameworks are Spring. There are many light weight alternatives.

> - maven / graddle build system that are completely bloated, in Go if you have your vendor folder checked in ( and you should ) you just do go build . and you have your single binary

It depends on how you configure them. golang's dependency management is non-existent, so no real comparison there.

> - 50 line stack trace that tells nothing

On the contrary, this is one of the biggest advantages of using the JVM or .NET. You get a stack trace telling you exactly where things happened. Compare that to golang where you get a single string and you have no idea which code path was taken to reach that error.

> - observability imo is better in Go, it's getting better with Oracle adding stuff into OpenJDK, but it was a pain before without paying ( jvisual vm, mission control ect .. )

The JVM is the most superior platform for metrics, measurement, and monitoring. This is an established fact, and anyone claiming otherwise shows they don't have experience in this area.

Re: Go 1.13: xerrors

#79

Post by AsyncAwait »

takeda wrote: post #71
AsyncAwait wrote: post #59

Earlier quoted context omitted.

Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be anoth…

> I wouldn't necessarily call Go's concurrency model superior

Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases.

> I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os

Is that OS written in Java or C#, because that's what the discussion was about.

Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered.

Also, size seems like an odd complaint to me in today's day of cheap disk space. On the other hand, simple deployment, no VM startup time and fast compilation speed do offer real advantages for some.

Re: Go 1.13: xerrors

#80

Post by apta »

takeda wrote: post #71
AsyncAwait wrote: post #59

Earlier quoted context omitted.

Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be anoth…

> but IMO Go would be another obscure language that no one cared about if it didn't come from Google.

The people who worked on golang also worked on another similar language called limbo before they were at google. You can guess where that one ended up.

Post reply on HN