The pros are of such value that they more than compensate for the cons: first class facilities for building concurrent programs and distributed systems. These are language features such as go-routines and channels and standard library includes for networking and RPC.

These are so great at what they do that they make programmers like me, who like Go, overlook the suck that comes from the existing typing system.

My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.

I see this repeated again and again. It's wrong.

The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type.

People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.

I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines.

More here: https://code.google.com/p/go-wiki/wiki/GoVsGenerics

Erlang is dynamic and has all those features :-)

It's true that the GIL in Python prevents interpreter threads to run simultaneously. But for many use cases it's OK to use gevent or multiprocessing (which share the same interface!). Channels are there in the form of queues, but there's no built-in support for selecting from multiple queues. To emulate that, you need an extra greenlet for each queue.

Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, and another step up from Go in terms of all the facilities for fault tolerant and distributed programming.

That said I can definitely imagine picking up Elixir for a purely imperative/OOP programmer being quite an undertaking. But definitely worth it.

[1] http://www.erlang.org/doc/design_principles/users_guide.html

I work as an Erlang dev. It is really awesome. It has a simple and consistent syntax (even if don't like the comma, semicolon and period terminators), the most powerful native concurrency semantics I know, the best error detection and handling semantics, pattern matching (you make the compiler work for you), an awesome virtual machine that took correct design choices (gc per process, iolists for concatenating strings), incredible tracing support, good support for connecting with other programming languages, a good optional type system (Dialyzer, http://learnyousomeerlang.com/dialyzer) for detecting type errors and good patterns as supervisor, gen_server and gen_event . It also has a vibrant community that has created good libraries like Proper (QuickCheck-inspired property-based testing tool for Erlang) and Cowboy (simple http server).

I have worked with C, C++, Java, Ruby, Python and Javascript/NodeJs. I really like Python and Ruby as general programming language and for creating prototypes, but I would definitely use Erlang for any real backend project.

Clojure is dynamic and has goroutine and channel constructs through core.async.

In other words, you have been reading about it, but never tried to learn it.

Go is incredibly easy to learn and prevents bugs and cruft as much as possible, makes writing documentation and testing painless and has good performance and concurrency support.

It also has a friendly, practically-minded community.

* benefits of static typing at low cost to the programmer thanks to type inference and duck-typing,

* intuitive and easy-to-use concurrency model based on channels and go routines,

* functions as first-class objects,

* very good performance,

* clean, concise and simple syntax,

* novel, low-overhead approach to build configuration based on the convention-over-configuration principle (your import statements express all there is to know about how to build your software),

* garbage collector.

I'm sure I forgot more.

Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.

Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway.

It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity.

> be pretty ugly and painful

Subjective. I like how it looks and have no pain.

> compared to javascript I can see the advantages though

It is not just "better than javascript". It is as expressive as ruby or python, with as much type safety as possible without giving up clarity or speed. And its type system doesn't require weeks to wrap your head around it.

Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations.

Is this supposed to convince C/C++ programmers? Like "sure your program will run 50% slower and have garbage collection pauses, but it compiles faster!". This just boggles my mind.

If you come from the world of scripting languages, a common style is "write between one and twenty lines of code; run tests; edit three lines; run tests...", where "run tests" might literally be that, or might just be running the code to sanity check that things are not too broken. In this style, even a twenty second delay would become very painful.

I think people who learned on C, C++ or Java tend to write much larger pieces of code in between run attempts, simply because it takes (or took) a while to check your work, instead of being effectively instantaneous. I know at a previous position where I did some Java development, the "tomcat stop; ant remove; ant clean; ant install; tomcat start... okay, NOW you can test" was quite difficult to develop against iteratively, sometimes being measured in minutes instead of seconds.

Ok this makes even less sense to me. In 10 years when Go has the completeness of these big Java systems it'll be even worse since there won't even be a dynamic loading option and the only choice will be to restart the entire system like that.

If you want to like Go because it has fast basic features and that's all you need that's one thing, but it doesn't have anything to do with compiling speed does it?

I like Go too, but lets not kid ourselves here. Ruby is vastly more expressive than Go. (I'm sure Python is too, but I am not a Python programmer, so I am not in a position to say).