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

61–70 of 150 posts

Re: Go 1.13: xerrors

#61

Post by zzzcpan »

aikah wrote: post #37
icholy wrote: post #24

Earlier quoted context omitted.

Dart also came from Google. Why isn't everyone jumping on that train?

Dart was born "for the wrong reasons" AKA replacing Javascript, it failed at it. The language itself is quite good, better than Go IMHO, but Go has the advantage of not requiring a separate virtual machine. The problem with languages is whether they get enough momentum so that a community can be built around them. A language without an extensive ecosystem is nothing. Also since Go is "hypocritically Object Oriented",…

> You can't write go without using interfaces for I/O.

You can and people do that all the time. You don't have to use its standard library I/O APIs, even its syscall package.

I'm not disagreeing that Go is OO though. Its ecosystem is dominated by OO. But it's more like Perl in this regard, where you can spend years without writing a single line of OO code yourself even if you have to use other people's OO code.

Re: Go 1.13: xerrors

#62

Post by apta »

sansnomme wrote: post #54
apta wrote: post #47

Earlier quoted context omitted.

> I wonder if go came from somewhere not google- how would it fare. There was a precursor to golang that the some of the same authors worked on before they were at Google. It didn't go anywhere, precisely because it didn't have Google's name behind it.

I think it was called "C", by Bell Labs folks.

Not quite: http://doc.cat-v.org/inferno/4th_edition/limbo_language/

Re: Go 1.13: xerrors

#63

Post by apta »

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.

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 Fibers, basically JVM managed lightweight threads, and has a strictly superior concurrency library in the form of `java.util.concurrent`. Not to mention libraries like Vertx and Akka for concurrency and actor systems.

Re: Go 1.13: xerrors

#64

Post by oppositelock »

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've been using Go heavily over the last five years, starting with 1.2. Whatever warts the language has in its design, the error handling being one, it's still an excellent language for getting work done quickly, and correctly. I'm far more productive in it than Java, C++, or Python, and I'm old enough to have done lots of Pascal, Lisp, and more scripting dialects than I can count.

Having been writing software over the 30 years that you mention, it's clear to me that Go has not been isolated from language design, it's just made a choice to stay simple. Java, C++ and Python have exceptions to keep you from littering your code with error handling, and code with exceptions is hard to read. The line of code you are looking at any point in time may instantly jump to another place, effectively, having "goto"'s evil cousin, the "comefrom". Somewhere, in your code, is a "comefrom" statement which runs immediately after the statement you are looking at, you're not aware of its existence. My Java/Python for production code ends up looking a lot like Go in terms of error handling, because you have the most context about an error at the point where it happens, so that is the best place to deal with it. I believe that Go 1.x will have the staying power of C.

Re: Go 1.13: xerrors

#65

Post by autarch »

jrockway wrote: post #56
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.…

My takeaway from the last 30 years in computer science is that errors are not exceptional. They occur often and should be accounted for near the code that generates the errors. Exceptions and return values are both sub-optimal. Exceptions encourage drastic actions for non-drastic events (exit the program if an HTTP server is transitently slow). Return values encourage ignoring the error value, and then wondering why…

Rust's type system + the failure crate (https://crates.io/crates/failure) is the nicest I've seen. It's similar to Haskell in that errors are part of the return value of a function, and the type system enforces handling of this.

_But_ Rust also includes some really nice syntax for passing errors through so I can write this:

    use failure::Error;

    fn foo() -> Result {
        may_return_an_error()?;
        might_return_a_different_error()?;

        if some_condition {
            return Err(MyPackageError { detail: "..." })?;
        }
        Ok("foo")
    }
The `failure::Error` type automagically wraps any error. That means I can go through many levels of my stack returning `failure::Error` and at any point in the call chain I can decide to examine the error type instead of writing `some_func()?;`, which would pass the error back.

The only part I don't like is that I need to add a `?` when I return my own errors. I don't totally understand this but from what I sort of understand the reason is that `?` invokes `.into()` on the returned object, which is what lets me return a (wrapping) `failure::Error` instead of a `MyPackageError`.

The upshot of all this is that "ignoring" errors is quite easy, as long as _somewhere_ in my call chain I actually do handle the error. The type system will enforce this for me, as attempting to treat a `Result` as just a String will cause a compile time error. I have to unwrap it and either ignore the error (which would lead to a runtime panic if there _was_ an error) or do the right thing, which is to explicitly handle both the ok and error cases.

I'm working on a CLI program using this system, and I can bubble all the errors up to the main entry point of the CLI. At that point I can turn errors into a print to stderr and an appropriate exit code.

Re: Go 1.13: xerrors

#67

Post by zzzcpan »

admax88q wrote: post #66

Go error handling. Slowly re-inventing Java's exceptions one use case at a time.

Weirdly enough this perspective might suggest that the problem is not actually with Go, but with object oriented programming. Which wasn't considered thoroughly by original authors, because they were not OO programmers.

Re: Go 1.13: xerrors

#68

Post by Thaxll »

apta wrote: post #63
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.

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 200MB of library to open a file or create a REST server

- 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

- 50 line stack trace that tells nothing

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

I worked with Java for many years and I can tell you that Go is a breeze of fresh air, it's not perfect but it's good for what it was designed.

Re: Go 1.13: xerrors

#69

Post by lmkg »

apta wrote: post #53
icholy wrote: post #24

Earlier quoted context omitted.

Dart also came from Google. Why isn't everyone jumping on that train?

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.

Re: Go 1.13: xerrors

#70

Post by whateveracct »

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…

Encoding Either as a product `(a, error)` instead of a sum `a | error` is a pretty big difference.

It becomes even sillier when you have to also signal "not found" with something like `(a, bool, error)` instead of `Found a | NotFound | Error error`

Post reply on HN