Interview with Go’s Russ Cox and Sameer Ajmani

Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.

1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place>

... if you want to get fancy and make sure all your binaries are automatically in your path

5. export PATH=$PATH:$GOPATH/bin

... at this point setup is done, to build your first project using an external library

6. go get github.com/<user>/<library> 7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package> 8. go install <your_package> 9. $ <your_package> # runs it

this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!

But it's fundamentally an open-source project. The only funding from Google comes in the form of paying some of the members' salaries. That's it.

I think the interest in Go has been increasing with or without Google's name tacked on to it, honestly.

Otherwise, you might as well say that the only interest in Rust is because it's funded by Mozilla?

Just playing devil's advocate here as I am a rust fan.

So every tutorial, every article, every video, every blog post is still an excellent source of information, 5 years later.

Rust? Anything you read that is more than a week old is basically wrong. Entire language features, syntax, keywords have been ripped and thrown into oblivion - the @ qualifier, the ~ qualifier, the entire i/o library is being rethought...

These aren't bad things. I'm a huge fan of not maintaining infinite backwards compatibility.

But it leaves a strange taste in my mouth. Go was basically "done" in the general sense in early 2010. Rust reinvents itself every 3 months. You could say that the Go authors knew better what they wanted from the get-go, maybe? There's a sense of "they know exactly what they wanted" vs "these guys are shooting in the dark and hoping to hit the bulls-eye" which is kind of the impression Rust leaves me with.

http://commandcenter.blogspot.it/2012/06/less-is-exponential...

There are still jobs I have done in the past that would require C today, but they were never suited for C++. Specifically it was work for realtime systems that required a highly trustworthy compiler like CompCert, the likes of which did not (and I believe still does not) exist for C++.

Rust is so unbelievably safe to use in complex, efficient systems. Rust is, IMO, the state of the art in programming languages.

Once you put the few months into actually getting OK at it you can write really great code, really fast and not be stuck with burdens since the compiler makes you write code that will work.

>> Go compiles easily (pay for it later!)

> By easily, I assume you mean quickly. How do you pay for it later?

I think they actually meant easily, not quickly, in the sense that the type system doesn't require a lot from the user. However, you pay for that later when your codebase becomes larger and you start experiencing bugs that could have been caught by a more sophisticated type system.

>> Rust doesn't compile easily but when it does there's a lot of guarantees.

> Like what?

Rust guarantees a number of kinds of memory safety. It's important to note that this is in comparison to C, not to Go (Go actually has stronger guarantees because of GC, I think). But Rust's strong typing also catches a lot of kinds of bugs that are hard to quantify mathematically but are pretty apparent to anyone who has worked in both strongly and weakly typed languages. I wouldn't call these "guarantees" but I would say that I'm definitely more confident in strongly-typed code than in weakly-typed code.

>> After picking up Rust I feel like Go just offers nothing.

> Why?

Because after using both languages, he hasn't found anything that Go offers. What exactly do you think Go offers that isn't available in other languages?

>> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM.

> It already is, in some ways. Can you be more specific?

For general use cases, the JVM has years of tuning behind it. You can't get more specific than that, as obviously there are some use cases where Go might shine. But as projects grow large, many use cases come out and it's highly unlikely that an arbitrary project will just happen to only have use cases that favor a new language without years of performance tuning behind it, especially when the designers of that new language shows no interest in looking at the last few decades of language research.

>> Want something less safe and easier to write in, why not use Python, etc?

> Go is less safe than rust?

Absolutely. Go's type system is decades behind. C++ has a stronger type system. Rust's, meanwhile, is extremely sophisticated, using ideas from strongly typed functional languages. There are some cases where compromises were made to allow low-level memory access which might allow some bugs which aren't likely in Go, but those are calculated compromises. Go's type system offers neither the safety of a modern statically-typed language nor the flexibility of a modern dynamically-typed language. Go's type system is just pitiful.

>> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.

> Why do you personally think that?

Because GC simply isn't to the point where it can be used for real-time programming, and systems-level access often is just easier to do with manual memory management.

>> it feels like a regression

> From what? Why?

From any other major recent language, because it offers no new innovations and actively doesn't include ones that have proven effective elsewhere.

From what I've seen over the last 10 or so years programming in both static (C++,Java,C#) and dynamic languages (Erlang, Python) things like "I got a string but expected an int" are pretty low on the list of what fails or brings a project down. Especially when it comes to distributed systems, thing like netsplits, logic and timing errors, mis-configuration, capacity overload are much more serious things.

Now you can argue static typing means really fast speed. And it is generally true. But lately with v8, PyPy and other such things that lines gets a bit blurry.

Channels are very easy to work with and both the scheduler and the large standard library are rock solid.

I used to us Haskell for building these kind of services, and it's awesome as well, but has pretty much the largest learning curve of any somewhat mainstream programming language.

Go, on the other hand, can be picked up in a couple of days by anyone familiar with C.

Rust has the potential to be awesome for these kinda services, but the learning curve will always be much higher than Go and right now the scheduling/standard library is still not comparable.

It's a very exciting language though.

So although Go does indeed have a well designed thread scheduler - I may discover after months of development on a project it isn't the thread system I need after all and now I'm stuck with a bunch of code I can't use.

Rust in general is far more underdeveloped than everything you mentioned and yes, right now, Go is probably a better choice - maybe.

Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10).

Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages.

As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.

If you're trying to solve problems caused by your language, maybe the solution is to switch languages.

> I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO

Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses.

The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.

It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite.

If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects.

'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.

For some reason, the core Go team has no need to write general algorithms/data structures. They just...write the code when they need to.

It's a strange way to think about programming, but for me, it can work. You focus on the "executable", not the "library" (I know that sounds strange...)

But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.

Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.

yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity.

at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.