Swift and Go: Building a Fast Future

I don't think being written in Go will make the compiler produce intrinsically fast code. Rather, it will be easier for them to iterate. It is much faster to develop in Go than in C.

They haven't written the optimizing compiler yet. They are waiting.

For what it's worth, the go team's plan is to automatically translate the compiler to go, not to rewrite it from scratch:

http://talks.golang.org/2014/c2go.slide#18

And, the gccgo compiler does leverage gcc, assuming that counts as a mature compiler:

http://blog.golang.org/gccgo-in-gcc-471

. Neither of these contradict your implicit point of "they chose to invest time in this port instead of trying to maximize performance ASAP", but you still might want to know.

Go can already leverage some of gcc's optimizations. There's also https://github.com/go-llvm/llgo

>I picked the 32 bit version of the benchmarks, since the demo program didn't need multiple GB worth of memory, FWIW.

More addressable memory is but one advantage of 64-bit versus 32-bit, the fact that it has double the amount of registers is another VERY important performance aspect since registers are by far the fastest place to store and retrieve data from, so less need to push values from registers on to stack / flushing cache lines, means faster running code, and in hot loops the difference in performance can be huge.

>Otherwise, I thought I was pretty clear why I picked binary tree over, say, mandelbrot set.

But why not show ALL the results and just highlight binary trees, there are a lot more benchmarks there than mandelbrot, also I don't see what is wrong with 'number crunching' benchmarks ?

It's not painful, the problem is that the code you write now might change in a month. With the release of 1.0 (which is less than six months IIRC), they will stabilize the syntax (but will be adding more down the line). But the libraries will still be very much in flux.

The reason things have been changing so much is mainly to get a better language now, and not have to write a 2.0 that changes everything. When you look at rust code from six months ago, things have improved greatly, so it will hopefully be worth it.

For better or worse, Go's design is anything but modern.

It lacks things such as immutability and generics. It also perpetuates the mistake of including a run-time type error, null (nil).

That it might have deserved the moniker if it had been released around the same time as java.

It was a dark age, and void stars filled the console. Many a core were dumped. An age where boys became men!

:-)

> However, I do think you really underestimate the compile speed of Go.

You mean like Turbo Pascal 4.0 back in MS-DOS?

Perhaps not 2 seconds, but I just checked and a 41,000 line Java codebase I work on compiles from cold in 3.4 seconds.

I'd never bothered with incremental compiling because the build times are so low, but I just tried now and changing 1 java file leads to a 0.3 second rebuild.

If you want to contrast compile speeds, try Go vs. C++. Java compilation has been very fast for a long time, as others point out.

For my part, my main beef with Go isn't necessarily the lack of generics, but the obstinate lack of expressiveness. It's back to Java or Python where you're forced to break up your code into discrete, imperative chunks instead of chaining stuff together in elegant flows. It's like Go's authors missed out on functional programming. No pattern maching, which seems like a huge miss considering Go has select { }. Go's syntax is, in many ways, even more rigid than both Java and Python.

That rigidity extends to error handling. While I agree with the philosophy behind Go's rejection of exceptions, I don't agree with how it's been implemented. In discussions about Go people always talk about exceptions vs. explicit error returns, but hardly anyone mentions the fact that error handling completely takes over our code: errs are everywhere!

A concrete example: Go has := for type inference, but it turns out you can almost never use it, because almost every function needs an "err" that you end up declaring. Often you start out like this:

    if result, err := getResults(); err != nil {
      return
    }

Quite elegant. But then you need to add some more code, and you actually can't rely on type inference anymore:

    var err error
    var result *Result
    if result, err = getResults(); err != nil {
      return
    }
    stats, err = computeStats(result)

It turns out that just because you needed another "err", you had to rewrite the statement, which is frankly ridiculous.

The next problem here is that we can't simply this:

    result, err := computeStats(getResults())

That's because computeStats() takes a Result, not two arguments (Result, error). In functional languages, this is elegantly solved through monads, but not in Go; you can't "short circuit" function chains that might return errors. There goes your expressiveness.

Another problem that the error phenomenon infects the language with is that you can't have global variables initialized this way:

    var spaces := regexp.Compile(`^foo`)

To get around this, the regexp module defines an alternative function:

    var spaces := regexp.MustCompile(`^foo`)

(Never mind the fact that you're not allowed to declare this as a const. It is a constant, I want it to be a constant, not a global variable!)

The fact that almost every function ends up having an "err" around raises the question: Why is it not an integral part of the language in the first place? Why do I have to declare err?

Other languages (Swift among them) fix this problem through sum types: The function can return a value which is either a real value or an error. Go's idea of returning a value and an error is logically nonsensical in almost every case, because the error is used to signify that the value isn't available due to failure. I'm not a language-theory purist who thinks everyone should really be using Haskell; these are practical concerns.

Overall, Go does feels disturbingly warty in places, which is incredible for a new, clean-slate language. Favourite wart: interface types being magically pointer-based, leading to the whole non-nil value being nil idiocy; it's mindblowing that they got this so wrong.

I liked Go a lot better before I started using it.