
Interview with Go’s Russ Cox and Sameer Ajmani - crawshaw
http://www.pl-enthusiast.net/2015/03/25/interview-with-gos-russ-cox-and-sameer-ajmani/
======
PopsiclePete
This quote: "Russ: The most important thing I learned is that a successful
programming language is about far more than the language itself."

and the article linked from that comment is why I think Go is posed to become
dominant over other new languages like Rust.

Go's documentation, tutorials, videos, support, community - what forms the
ecosystem, basically - is really the reason why I keep coming back to it.

The core language might not be super-exciting, and it might not be as fast as
others, as elegant as others, as "powerful" as others, as feature-rich as
others, but the overall experience is very, very pleasant.

~~~
azth
> and the article linked from that comment is why I think Go is posed to
> become dominant over other new languages like Rust.

Apples to oranges. Rust is aiming to be a C++ replacement.

~~~
nemo44x
After using Rust I see no reason why C++ should exist any longer. Maybe in
really limited embedded systems.

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.

~~~
weland
> Maybe in really limited embedded systems.

Given the incredible complexity of C++, I would _much_ rather see Rust or Go
come to those systems rather than C++.

------
nemo44x
I like Go and was seduced by channels and go routines. But, I found time to
learn Rust (still learning really - Rust is an epic and amazingly rewarding to
learn!) and have to admit Rust is far and away the most modern, state of the
art and most important programming language of our time. Go compiles easily
(pay for it later!) and is sponsored by Big-G. Rust doesn't compile easily but
when it does there's a lot of guarantees. And, it does concurrency just as
well. Apples to oranges really though.

After picking up Rust I feel like Go just offers nothing. Why not use Java or
.Net instead of Go? Highly unlikely Go will be more performant than the JVM.
Want something less safe and easier to write in, why not use Python, etc?

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.

Go has a couple built-in features that other languages can and will get with
library addition. Go is a 1-trick pony I feel sometimes. It's an "in thing"
that doesn't serve much of a purpose overall I feel. It looks like C but lets
face it, it's nothing like it in terms of performance and never will be. It
isn't a replacement for C.

Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who
knows. But, after using it for awhile and letting the glimmer fade, it feels
like a regression. Developers, developers, developers!

~~~
logicchains
Go has an well-designed, integrated lightweight thread scheduler. The only
popular languages with equivalent lightweight threading systems are Haskell,
which takes orders of magnitude longer to master than Go, and Erlang/Elixir,
which lack static typing. There's also Clojure with Pulsar, but Clojure lacks
statically typed libraries, and the Java equivalent of Pulsar, which is ugly
to use compared to goroutines as it's not a built-in language feature and Java
syntax can't easily be extended like Clojure's.

Rust has libgreen, but it is extremely underdeveloped compared to the
schedulers/runtimes mentioned above. For developers interested in static
typing, lightweight CSP-style threads and ease of learning, Go hence currently
represents a much better choice than Rust.

~~~
rdtsc
> and Erlang/Elixir, which lack static typing.

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.

~~~
nostrademons
In my experience - also using both static (C++, Java, Go, Sawzall) and dynamic
(PHP, Python, Javascript) languages - I don't get type errors either.
_However_ , what actually brings dynamic languages down in larger systems is
the time spent tracing through code to figure out what the _actual_ type of
the variable is, and hence what you can do with it. When a script is small
this is negligible, but when you've got large teams and hundreds of source
files, you can spend 10x the time doing this than actually coding.

I view static typing as essential to larger projects, but for documentation
reasons, not performance. The performance and error-checking is a nice boon,
but you can recover the former with smart VMs and the latter with unit tests.
The documentation can only be recovered by writing your types out in comments,
where they won't be checked by the compiler and invariably become out-of-date.

~~~
rdtsc
You are right, it would help with documentation, good point.

In general I use integration and unit tests for checking breakage. And of
course documentation is in comments but that is not forced. The first set of
unit or integration tests also function as "example code". Even when reading
documentation I usually gravitate to "examples" section quickly anyway.

I just had smaller components that are rather independent if I can. It depends
on the project of course. I guess I've been doing micro-services before they
were cool.

------
JulianMorrison
I think Go's unique selling point is: it's the anti-LISP, the programming
language that isn't particularly programmable and you don't miss it, because
the built-ins are sufficient. As a result, code in Go tends to be far more
about solving the problem than is the norm; in most languages, you'd first be
solving the language or replacing the stdlib. Concurrency is an example, yes,
but so are the HTTP and the TLS libraries.

~~~
mrottenkolber
> the anti-LISP

Agree. It has message passing with a nice thread model, and the engineering
seemed sound when I experimented with Go a few years back, but it lacks
everything I need in order to actually program.

~~~
4ydx
Interesting. It is the polar opposite for me.

------
4ydx
Another post about Go where the Rust crowd comes out to play. I cannot wait
for your language to stabilize so that you will no longer feel the emotional
need to bash on golang :)

~~~
kibwen
Moderator of /r/rust and #rust here, I honestly have no idea where these
people come from. We have rules against language bashing, so I guess we ended
up exiling them all to HN?

------
bhickey
The lack of generics in Go is a non-starter for me. There's polymorphism in
built-in types, but these throw out compile time correctness guarantees.

~~~
zimbatm
In the other hand, it helps prevent people to build needlessly complex
abstractions. That's what I like about go: relatively straight-forward code to
read in most project that I have seen.

~~~
spotman
agree. when it's 3:42am and you get called in to debug something in a
production system in the middle of the night, it's a hell of a lot quicker to
visually and mentally parse and digest golang without all these abstractions
and "elegant" ways to do things. (than some languages like java)

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.

~~~
danieldk
_agree. when it 's 3:42am and you get called in to debug something in a
production system in the middle of the night, it's a hell of a lot quicker to
visually and mentally parse and digest golang_

You think this that functions returning _interface{}_ are easier to debug than
functions that return a specific type? Because that's exactly what you are
throwing away with generics.

Allowing specification of the element type of a container data structure is
not unnecessary abstraction, it's type safety!

~~~
spotman
while that's an example that I do see in the wild, not every function returns
interface. but it doesn't really hurt my argument.

if I have a function that returns an interface I can grep who is calling it
and probably digest what it is within a few moments and probably 2 or 3 files
of code.

with java I find its so once you get through the factories, abstractions, and
more, I have never found what I'm looking for in 2-3 files until I am more
intimate with the code base.

~~~
danieldk
_with java I find its so once you get through the factories, abstractions, and
more_

Most of the typical design patterns do not hinge on generics or even
inheritance and can be implemented easily in Go too.

