Go’s runtime C to Go rewrite, by the numbers

- C-style systems programming without C-style catastrophic security bugs

- "real binaries"

I think it's better than say C og C++, because I have an easier time understand and writing Go, but that's very individual and may not apply to others. I don't like Java because of it's verbosity and overly complex ways of doing simple things, but I haven't looked at Java for years, so that may have changed.

As far as Go over Java, in terms of differences:

1) Error codes instead of exceptions, big difference, puts Go more in the 'write a server' than 'write an application' category although those lines have been blurred

2) Duck typed interfaces, type inference, automatic delegation and whole bunch of useful little things that make Go, IMO, "Java done right". Regardless of the fact that most of the Go community would want to punch me for calling it that. Go's conventions encourage 2010s Java, Java can sometimes encourage 1990s java.

3) Goroutines being first class is quite different from always instantiating/passing-around an ExecutorService.

4) First class functions and lambdas, although lambdas are a little less useful for not having generics.

Rob and Bjarne know each other from Bjarne's time in the Unix lab. The had philosophical differences, Rob tells of Bjarne's storming outbox a conversation.

Some of us trust Rob's judgement, having been treated kindly by it before, so we will walk down his path and trust where it is leading. When Russ Cox joins us, we know for sure that the path will be safe and the walk will do us good.

For me, that blandness brings great simplicity - which makes it refreshingly easy to learn and write code in that language. It also helps with those "what the hell was I drinking when I wrote that code" moments that even the best of us suffer from time to time.

Also I love the brevity of the code required to build something in Go. I find Java frustratingly verbose.

Lastly, Java is in many ways more portable than Go (compiled Jar's are platform independent and JRE's have been ported to more platforms than Go's compiler), Go's compiler makes targeting other OS's and architectures a doddle plus it's sometimes more convenient to ship a static ELF / PE without worrying about having the appropriate runtime environment at the destination.

There are some things I miss from Go that are present in Java (amongst other languages) such as better support for GUI development, more flexible namespaces and such like. But, for now, Go addresses more desires than it creates complaints.

Focusing on X is the wrong thing to do. What has attracted people to Go is the fact that you can build stuff

- quickly

- with good performances

- easily deployable

- reasonably solid

- can be shared and understood between a lot of engineers at the same time

This featureset seems to match with Go. I have very little experience with other languages, so I can't say Go is the only one that can do it all.

As for what the Go language is, allows or does... that's really not the point. What matters is what you build with it and how you can build it.

1. Its build tool is simple. 2. It compiles incredibly fast. 3. It is native compilation with no runtime required. 4. It enforces uniform code formatting, and is strict with no compile warnings. 5. It has a standard build tool and standard test tool. 6. It has a standard documentation tool. 7. Only requires a single environment variable GOPATH for all autocompletion to work out of the box WITHOUT an IDE. No IDE project files necessary. 8. Its a decent language that can be learnt quickly. 9. It has CSP.

You are criticizing point 8 out of context, Go is a sum of its parts.

There are many types of code that are significantly longer in C# or java than in C, just because C lets you do crazy things with memory mapping.

To get more terse code, you need to switch from the C family of sytax imo.

In short, the Go code in the runtime is about at the same level at C code.

Don't forget that this is a straight 1-to-1 translation; this is not the time to introduce new bugs. After it's all done, the runtime code can be refactored and it might become cleaner and smaller.

PS: there are no go errors, and hence no if err != nil statements in the runtime.