ianlancetaylor

Rob Pike retired from Google a few years back.

You can use it with other functions that use iterators. For example, here is code that makes a copy of a map keeping only the even keys.

  maps.Collect(xiter.Filter2(func(k, v int) bool { return k%2 == 0 }, maps.All(m)))

Yes.

The default proxy has a privacy policy: https://sum.golang.org/privacy.

I'm not going to claim that Go has the ideal approach to whether an error can be ignored. In general, in Go, some errors can be ignored, and some can't. For example, fmt.Fprintf to a strings.Builder can never result a non-nil error. It's fine to ignore the error returned by fmt.Fprintf in that case. On the other hand, fmt.Fprintf to a os.File can return a meaningful error, and for some programs it's appropriate to check for that error. (Though the issue is complicated by the fact that complex programs probably use bufio which does its own error handling.)

I'm not personally concerned about examples like os.Open, where the result must be used. Sure, you can ignore the error. But a failure will show up very quickly. I'm not saying that this is not an issue at all, but I believe it's a less important one.

Part of the reason for Go's behavior is the idea that "errors are values" (https://go.dev/blog/errors-are-values). And part of it is that the simple fmt.Println("Hello, world") doesn't require any error handling. And part of it is the desire to make error handling clear and explicit in the program, even if the result is verbose.

Go made a deliberate decision to use multiple results rather than Option<T> or Result<S, E>. It's of course entirely reasonable to disagree with that decision, but it's not the case that the Go language designers were unaware of programming language theory or unaware of sum types. Although you suggest that you want sum types as the primary tool for error handling, Go made a different decision, not due to accident or lack of knowledge, but intentionally.

(Separately, I'm not entirely sure what you mean when you say that Go doesn't use interface types for its error handling, since the language-defined error type is in fact an interface type.)

As it happens, we considered sum types quite seriously in the early days. In the end we decided that they were too similar to interface types, and that it would not help the language to have two concepts that were very similar but not quite the same. https://groups.google.com/g/golang-nuts/c/-94Fmnz9L6k/m/4BUx...

There is a lot of discussion of sum types in Go at https://go.dev/issue/19412.

There is no ambiguity there. The ambiguity arises for parameterized types.

type A[T] int

Is that a parameterized type named A with a type parameter T, or is it a definition of an array named A whose length is T?

Separately, it's nice that type parameter lists use the same syntax as non-type parameter lists.

Very little. The announcement here is not a new draft, it is starting the formal proposal process for adding type parameters to the language.

There isn't a code review for the changes on the dev.go2go branch (though you could construct one using git diff).

The dev.go2go branch will not be merged into the main Go development tree. The branch exists mainly to support the translation tool, which is for experimenting with. Any work that flows into the main Go development will go through the code review process as usual.

Remember that they are only pinned to an old language version. They will still work fine with new release of Go, they will just be built with the old language semantics. So what's the harm?

I agree that unmaintained libraries that don't adapt to modules could be a problem. We'll have to see what happens.

Go could introduce a moving GC without requiring that map keys not be interface types. The simplest approach would be to use read barriers as we already use write barriers, and forward pointers during the moving phase of the GC. (Efficiency costs might prohibit that, but it could be done.)

Another approach would be to use two different map implementations, and use a less efficient one for older code that used an interface type as a map key.

It's an interesting example, though. You're right: if there is an old language feature that can not be supported by a newer runtime, then there needs to be some sort of shim to let the older code keep working. That necessity may prevent us from making certain sorts of language changes.

One step at a time. It's certainly a natural extension, and I don't think anything in the current design draft precludes it.

Unfortunately [T] is also ambiguous with the current Go syntax. The parser can't distinguish an array declaration from a generic type.

Thanks for the comments. We tried for some time to declare contracts like interfaces, but there are a lot of operations in Go that can not be expressed in interfaces, such as operators, use in the range statement, etc. It didn't seem that we could omit those, so we tried to design interface-like approaches for how to describe them. The complexity steadily increased, so we bailed out to what we have now. We don't know whether this is is OK. We'll need more experience working with it.

I'm not sure that Go is a language in which higher-level abstraction is appropriate. After all, one of the goals of the language is simplicity, even if it means in some cases having to write more code. There are people right here in this discussion arguing that contracts adds too much complexity; higher order polymorphism would face even more push back.

In this case the mismatch is between a type argument and the way that a type parameter is used, so it's not a type mismatch/error, it's a meta-type mismatch error. You are suggesting that the meta-type be inferred from the function (and any functions that it calls) rather than being explicitly stated. That is doable--C++ does it--but it means that the user has to understand the requirements of an implicitly inferred meta-type. The Go design draft suggests instead that the user be required to understand an explicitly stated contract.

The blog post explains that.

What is an "unmarked check call"?

Yes, the various fmt.Print functions only return an error if Write on the underlying Writer returns an error.

And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.

I don't think there is any lack of clarity about your List example; that is clearly forbidden. The example that is less clear is the one that generates a million types and then stops.

A similar issue arises in C++; the C++ standard says that there is an implementation defined limit on the total depth of recursive instantiations. Perhaps Go should do something similar.

That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.

A year ago we said it was time to move toward Go 2: https://blog.golang.org/toward-go2 . This is another step in that direction.

Yes, what you write should work with the current draft.

Read the design draft (https://go.googlesource.com/proposal/+/master/design/go2draf...). The issues you raise are addressed.

The mysterious "plugin" package does not yet exist, and won't be in the 1.5 release. I would encourage you to try to implement it and send in the changes. The ideas in the execution modes doc are being steadily filled in by people who need them.

The fact that it's not necessary to explicitly state which interfaces are implemented by a type is a key design decision in Go. It's not going to change.

Every language decision has pluses and minuses. I think most Go programmers feel that this problem is fairly hypothetical because it doesn't seem to come up for most people in real code. But, you're right, it's possible for it to come up. Every language decision has minuses, including this one.

But the pluses outweigh the minuses, so this is not going to change. Sorry.

I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go.

(Personally, I don't mind the ongoing discussions about generics in Go, I just wish they were less repetitive. It's very easy to say "add generics to Go!" It's a little bit harder to actually do it well.)

I think that experienced Go programmers simply write the code using the types they need.

I think the essay is entirely correct: there are certain patterns that are difficult to write in Go. It's hard to write generic code that merges two channels into one. It's hard to write generic code that acts as a future.

But it's easy to write type-specific code to perform those operations. Most Go programs do not need to merge channels of many different types. So people simply write the code they need when they need it.

This is not to say that there is no use for generics. There is clearly a use for generics, and examples using channels are among the strongest use cases. I'm just trying to answer your question about what Go developers actually do.

But it's in the map, so it's in use.