Keyword arguments

If these are important, you can get a pretty good approximation with structs, e.g.

type Point struct{ X, Y float64 }
func EuclidianDistance(p Point) float64 { ... }
d := EuclidianDistance(Point{X: 3.0, Y: 9.6})

—

Absence of sum/discriminated-union types

Because reposurgeon events can have any one of a set of types (Blob, Tag, Commit, Callout, Passthrough, Reset) I found myself writing a lot of stupid boilerplate code like this:

Yeah, type assertions usually aren’t the way to go, as they’re not runtime-safe. Generics will make this better but the best approach right now is a non-discriminated union type e.g.

type Event struct {
    *Blob
    *Tag
    *Commit
    ...
}

and checking for nils.

—

Catchable exceptions require silly contortions

Go does not have exceptions. Using panic/recover as ersatz exceptions is essentially always a design error. If you ever find yourself trying to recreate an exception control flow, you are almost certainly on a bad path.

I kept looking at places where existing nonlocal control transfers in Python could be replaced by explicit Go-style passing upwards of an error status. But I noticed that there were a significant percentage of cases in which doing this made the code more difficult to follow rather than easier . . . An early reviewer pointed out that if the Go code were an entire function it could be expressed something like this . . . That’s still a lot of eyeball friction compared to functional-style with exceptions. And it gets worse faster as the number of stages rises.

Effective use of Go requires the programmer to choose to see that example function as wonderfully explicit, rather than full of “eyeball friction”. I’ve said this many times: in Go, the happy path is equally important to the sad path. You have to just accept that and work with it, or you’ll hate the language.

—

Figuring out how to do type-safe polymorphism in the event list

Go does not currently support type polymorphism. Generics will change that, but at the moment, trying to approximate it is a sure-fire way to frustrate yourself and produce bad code.

—

1. Keyword arguments should be added to the language.

Emphatically no.

2. True iterators are felt by their absence and would be easy to add.

Not without sacrificing the performance goals of the language.

3. Any enlargement in the range of what can be declared const would be good for safety and expressiveness.

+1.

4. Yes, throw()/catch() needs to be writeable in the language. Two minimal relaxations of compilation rules would make writing it possible.

Emphatically no. One of Go’s fundamental opinions is that exceptions are bad. You have to buy in to that. If you don’t want to, no problem! Go isn’t the language for you.

5. A technical writer with an outside-in view of the language should be hired on to do an edit pass and reorganization of the documents.

+1.

6. Lookbehinds should be added to the regexp library.

There are good reasons this doesn’t exist currently. It’s unlikely to change.

Some of these I agree are real pain points, but in the case of others the author is suggesting making changes to the core language with little argument beyond accommodating what is a frankly really bizarre situation – wanting to transliterate a large python codebase into Go without having to make non-trivial changes to the way the program is written. In particular, you can get into arguments about the value of exceptions, but making porting code from another language easier strikes me as a dramatically weak argument.

Unrelatedly, there’s a slightly safer version of the type switch you can use:

switch v := child.(type) {
case *Commit:
        successorBranches.Add(v.branch)
case *Callout:
	complain("internal error: callouts do not have branches: %s", child.idMe())
default:
	panic("in tags method, unexpected type in child list")
}

…which at least doesn’t require the type assertion. You can also kindof limit what variants are possible, by (ab)using an interface

type MyUnion interface {
        isMyUnion()
}

func (*Commit) isMyUnion()
func (*Callout) isMyUnion()

The method being lower case will mean that you can’t extend the type by defining that method in other packages, though you can embed the interface, so it’s not foolproof:

type Foo struct {
        pkg.MyUnion
}

…and it still doesn’t do exhaustiveness checking for you, though it wouldn’t be that hard to build a tool that recognized this pattern and did so.

This pattern sees use in the go/ast package.

It is definitely a hack though, and I miss sum types when working in Go.

I feel like a lot of the language limitations described in this post are based on expectations from other languages. Some of them are valid points that have known workarounds (e.g. representing sum types as a types satisfying an interface with private method), and I absolutely agree that current Go documentation doesn’t make a good introduction to the “Go mindset”. That said, Go is not Python and some things work and/or should be implemented differently.

For example (exception control flow): if the transformations are expected to fail, they should return an error (or at least a bool indicating a failure). To run these in pipeline, you can define transform function to return an error and accept the result of the previous transformation (suboptimal, but closest to the Python implementation).

func pipeline(source T) (T, error) {
	return transform3(transform2(transform1(source, nil)))
}

func transform1(source T, err error) (T, error) {
	if err != nil {
		return nil, err
	}
	// …
}

Or we could define a method on T that accepts a list of func(T) (T, error) transformations and either applies all transformations in order or returns early on error.

func pipeline(source T) (T, error) {
	return applyTransforms(source,
		transform1,
		transform2,
		transform3,
	)
}

func applyTransforms(source T, ts ...func(T) (T, error)) (T, error) {
	var err error
	for _, f := range ts {
		source, err = f(source)
		if err != nil {
			return nil, err
		}
	}
	return source, nil
}

IMO that’s way more concise compared to f(g(h(v))) right-to-left transformations.