Next steps toward Go 2

The "Go is performant" gospel seems to be coming from people who came from Python and JavaScript to Go. I don't think Go prioritizes performance more than most other popular statically-typed language Java[1], Haskell or Swift (or less popular ones like Ocaml).

And Go obviously doesn't prioritize performance as much as C++ or Rust. Case in point is with very same error handling proposal discussed here. You're going to have to pay a performance price for using a handler since the Go compiler not only avoids inlining defer blocks (if I understand correctly), but even allocates dynamic memory for each block. Meanwhile, equivalent RAII in C++ has no overhead over manual code.

Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases.

This approach makes me sad, because Go does have the engineering power and stated design goals to be more serious about performance. Yeah, I feel confident Go will keep improving, but just the same as Java does (without the same hype).

[1] Although until recently they did have radically different choices about which kind of performance to optimize, e.g. Java went up with throughput (Throughput-optimized, JIT tricks for fastest execution after warmup), while Go went for low worst-case latency and faster startup time.

I have to say, as time goes on, the more I like contracts. Go concrete types can satisfy go Interfaces. Go concrete types and Interfaces can satisfy contracts.

I would actually feel better if the proposed generics were a little less powerful. Composing generics can get ugly. This could be countered by community norms, however.

Yes there are languages that are easier to work with, and yes there are languages that are faster. If you want to support hundreds of millions of users and have a relatively small dev team, Go is one of the best options out there since it's both performant and productive to work with.

In fairness to Go, there is a precedent for built-ins to be "special" in ways like this. So e.g. while there are no user-defined generic data types, the built-in collection types like array are generic.

The Zen of Rust is very much in the direction that standard operators shouldn't be more "special" than necessary, and a lot of fundamentals become "library-able" or at least library-extensible. Go simply doesn't take this approach. It's a more opinionated language, and it some cases that means you get the tool it makes for you, rather than getting to craft your own tool for yourself.

Isn't "generics for me but not for thee" already a core part of the Go philosophy?

Go already has "append". It would be similar in that sense.

panic() and recover() are a built-in function, so there is already some precedent for doing this.

It's just syntactic-sugar. From the proposal (https://github.com/golang/go/issues/32437):

    f, err := os.Open(filename)
    if err != nil {
        return …, err
    }

is simplified to:

    f := try(os.Open(filename))

> I dislike the try implementation

What would you suggest instead?

I think it's going to be fine.

It doesn't encourage skipping error handling, it just allows skipping annotation where it doesn't add much. Sometimes in a chain of several calls, a function in the middle can't really add much context, and is better just to bubble the error up one level without annotation - that is what try is for.

In what way does Go do errors better than Scala though? Error handling is _more_ first class in Scala, not less.

I don't think applicative/monadic error handling is an afterthought in any way. There are combinators to recover, for instance. But it's optimized in such a way that you can focus on the happy-path of your code and you get a sensible default for error-handling (short-circuit..just like Go's idiom!)

To me, the `try` implementation is brilliant.

It achieves what a real monadic Either / Result implementation would achieve in error handling, it stays simple, and it's backwards compatible.

While I'm not a fan of Go in general, I can't help but admire at achieving all this so simply and cleanly (as much as the underlying return-two-values thing can be considered clean).

This looks pretty much exactly like the old try!(expr) macro in Rust, which has since been replaced with the postfix `?` operator.

One crucial difference is that the proposal uses a named `err` return value that can be manipulated in defer. This is supposed to allow cleanup and wrapping of the error type.

Rust solves wrapping is by allowing auto-conversion between error types (if they implement it).

My first intuition is that it would be an improvement over omni-present `if err != nil {}`, but it feels somewhat awkward and tacked on. Especially the mutable `err` return value.

Of course there also was a reason why try! was replaced with `?`: awkward nesting and chaining. Go would have the same problem.

It looks like instead of making a better error handling system, they just made it easier to not type `if err != nil` everywhere. Then there's all that handler stuff that looks very much like Java's `try ... catch` in reverse order.

Pretty underwhelming for what's supposed to be a modern language.

They aren't really moving forward with it, they are implementing an experimental version of it so people can try it in real code. Many things are added temporarily when a new version is in development. Eg. the error handling changes they mentioned were implemented, and then later most of it was removed before the feature freeze.

So there's still plenty of time to stop the proposal.

My main beef with this and other proposals is that they don't clear up a fundamental flaw in Go: Multi-value returns with errors as a poor man's sum type.

Most functions in Go have a contract that the return values are disjoint, or mutually exclusive — they either return a valid value or an error:

    s, err := getString()
    if err != nil {
      // It returned an error, but "s" is of no use
    }
    // s is valid

This pattern so ingrained that there's hardly a single Go doc comments on the planet that says "returns value or error". The same goes for the "v, ok := ..." pattern.

But this is just a pattern and not universally true. A commonly misunderstood contract is that of the `Read` method of `io.Reader`, which says that when `io.EOF` is returned, the returned count must be honoured. This is an outlier, but because the convention of disjointness is so widely adopted, many developers make this assumption (it's trivial to find repos in the wild [1] that make this mistake), and so this is, in my opinion, bad API design.

(As an aside, it's also true that multi-value returns beyond two values almost always become cumbersome and impractical, especially if said values are _also_ mutually exclusive. Structs, having named fields, are almost always better than > 2 return values.)

This kind of careless wart is typical of Go, just like other surprising edge cases like nil channels (or indeed nil anything).

I would much rather see a serious stab made at supporting real sum types, or at least mutually exclusive return values. For example, I could easily see this as being a practical syntax:

    func Get() Result | error {
      ...
    }

This union syntax showed up in the Ceylon language, and it's a neat pattern for a conservative language that doesn't want to venture into full-blown GADTs.

Such a syntax would be a much better match for a try() function, since there's no longer any doubt about the flow of data — there's never a result returned with an error, it's always either a result or an error:

    result := try(Get())

or simply support existing mechanisms for checking:

    if err, ok := Get().(error); ok {
      ...
    }
    if result, ok := Get().(Result); ok {
      ...
    }
    switch t := Get().(type) {
      case Result:
        // ...
      case error:
        // ...
    }

I'd love to see a `case` syntax that allows real local variable names:

    switch Get().(type) {
      case result := Result:
        log.Printf("got %d results", len(result.Items))
      case err := error:
        log.Fatal(err)
    }

And of course, you could have more than two values:

    switch Get().(type) {
      case ParentNode:
        // ...
      case ChildNode:
        // ...
      case error:
        // ...
    }

The Go compiler can be strict here and require that every branch be satisfied or that there's a default fallback, although some might prefer that to be a "go vet" check.

A full-blown sum type syntax would be awesome, though I know it's been discussed before, and been shot down, partly for performance reasons. Personally, I think it's solveable. I'd love to be able to do things like:

    type Expression Plus | Minus | Integer
    type Plus struct { L, R Expression }
    type Minus struct { L, R Expression }
    type Integer struct { V int }

[1] https://github.com/search?q=%22read%28%22+%22if+err+io.EOF%2...

It looks like a monad for Either or Result to me, and I think it's an improvement.

The good news is if you hate it you don't have to use it, but since it'll be in the language (if they take it) you'll have to know how it works.

I don't think this is worse than things like "for:else" in Python.

The statement looks like an assignment, and unless I was really used to seeing it, I would never expect an implicit return.

What the hell happened to the catch/handle draft proposal. That looked a lot more useful

One of the most common issues (from surveys, etc) that Go users want to see addressed is verbose error checking, and this proposal is to add some syntactic sugar to make one of the more common error checking idioms less verbose, in order to address that specific issue.

You are suggesting that they implement a metaprogramming system (and then build this solution on top of that) instead? On the grounds that it will reduce cognitive load overall?

Surely that is a drastically more difficult solution to the problem this is meant to address. I think it might be difficult to implement that in a way that maintains key properties of Go (like consistently fast compile times), and it might add a lot more work to tooling that needs to understand code like editors etc. And although that would allow each Go project to invent their own error handling mechanisms, and some projects might benefit from that, there's clear downsides to that as well.

Having read a decent amount of go code I'm really quite convinced the restrictions are beneficial. Personally I find it easier to read than just about any other language.

I'm of the opinion that making a language too simple results in the worst code. Sure it's easier to learn, but you end up with crap when you're trying to do something complex and there's no good way to represent it.

BASIC and VBA are extreme examples but they support my opinion :).

Go has a ton of shortcomings. No good popular package management system with versioning, hacky JSON parsing, no generics. Rust is becoming a good counter example, they listen to the community and pump out features that everyone is excited about. Like async recently.

Google has a habit of ignoring the community. Angular is a great example. I've been following a feature request for close to 3 years that has over 100 comments asking for it. A simple thing too. Many people have opened PR's and begged for it in vein, even as recent as a week ago.

it's much less magic than defer, panic and recover - it's basically just a macro. if that irks you, all of the above should make you hate the language.

> Go is less expressive than certain languages, it wins in clarity and readability.

Not having to deal with inheritance is clear and readable enough. Generics wouldn't make the language less clear and readable. Furthermore, it's not an ALL or NOTHING case. Generics could be restricted to generic functions for instance, not types per say. Go already makes a lot of trade-offs, i don't see why this trade-off would be controversial.

But to me generics are the least of Go's problems. A lot could be done to make the language easier to use, like co-variant interfaces for instance, a tons of other stuff could be added in a relative "invisible" fashion that would not impact the language's syntax.

Yep, quite readable.

https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...

All of these have already been discussed in the GH issue. It is all being taken into consideration. Check out https://swtch.com/try.html for a thematic grouping of the issue.

An improvement, really? It seems to me that it reinforces a bad pattern (returning an error directly without annotation) and will make return analysis of functions in code review a lot harder. For what, to reduce typing? Doesn't strike me as a good tradeoff, and certainly feels at odds with Go's principles so far.

It looks like a big improvement but it's definitely not monadic. It's a hidden return.

Yeah, and this new change doesn't alter how explicit the code is. The new "try" just means "return error from here without setting the LHS if the RHS returns an error". It is the standard boilerplate captured.

When this is in common use, it will greatly improve the visibility of non boilerplate error handling.

> - Adopt crypto principles.

Turn a profit by pumping crappy tech to the masses?

Why is there a defer in the "try" example? To just show wrapping even though the "existing" one doesn't wrap? Also, the "try" example doesn't defer-close "w" in case copy fails. Seems that they aren't the same example.

LOC reduction of 10% with check/handle statements and 20% with try()/defer along with somewhat reduced clarity of what will happen on error.

I'm not a fan of the verbosity at present either, but seems like the check/handle syntax is less direct and the try()/defer func syntax is less flexible.

Funny how it's also wrong.

  handle err {
      w.Close()
      os.Remove(dst) // (only if a check fails)
  }

the error returned from w.Close() is not handled.

Funny, I thought I would like the ”try”, but looking at these examples I prefer the Go1 version.

That isn't really the sort of thing Golang is trying to address, at least, not directly. Go is very unlikely to add immutable data structures at this point. And Go is not built to prevent race conditions. There is a race detector that can detect many race conditions in running programs, but nothing in the type system.

The purpose of channels is to provide synchronisation and messaging between goroutines, not to prevent race conditions on shared data.

Go also provides mutexes that are more suited for that.

Sure, passing a pointer through a channel does not in itself provide any protection to the data it references but such protection is not always required. There's a separation of concerns that allows more flexibility.

> This means that once we send a pointer on a channel, it's game over

Yes, as long as you keep sharing the references. So just don't reference that stuff you sent across a channel. Usually there is little reason to use pointers in Go anyway [1] except when building methods to mutate the associated type (think: struct).

That said, it's fairly easy to build cascaded structures that are automatically deep-copied during assignment by not using pointers. So that's a pretty safe way to go, moreover one should keep in mind that Go doesn't try to be functional in any way, so immutable data is not such a thing there.

[1] https://medium.com/@vCabbage/go-are-pointers-a-performance-o...

They did not want to create a new "keyword" that would possibly conflict with some existing variable name. So try() is a built-in function, similar to len(), and if you already have a variable named "try" (or "len") then it shadows the built-in (takes priority in that scope).

It's mentioned in the design doc under "Properties of the proposed design": https://go.googlesource.com/proposal/+/master/design/32437-t...

One possible reason is that funcall semantics will probably change (Go 2 is likely to have generics), and so simple funcalls keep the language orthogonal; new operators are forever.

came here just to make that joke :(