Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything that does sync I/O).

Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives"

99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.

Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams.

Erlang, however, is much better at distributed concurrency. There are few who suits this use case better.

As in all cases. Use the best tool for the job.

Erlang is actually compiled, and binaries above a certain size are reference-counted rather than copied between processes. It still makes various compromises like using bignums and doing preemptive scheduling which make it slower in general.

It's compiled to erlang bytecode, yes, but not to machine code. You do have the option of doing that, but I do believe you miss out on live updates? Not sure.

Erlang is great though, especially Elixir, but for some use cases Go is better.

If the first paragraph is the extent of your concerns with Erlang (which are reasonable), they are more than addressed by Haskell. Compiled and very statically typed.

Yeah, but it's more difficult to teach others Haskell (what's a monad?) than Go. I know all three languages, I mostly prefer Go for backend work because it's easier for others to join in on.

Point is that they all have their strengths, but one is not necessarily better than the other. As with all things digital, it depends.

> Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives"

I commented before your edit. The question I responded to was something like "What can you do in Go that you can't do in C++ or Java?"

> 99% of projects don't need green threads.

Perhaps not need, but many of those projects are paying a large opportunity cost in today's no-free-lunch, multicore, I/O-bound world.

> But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang.

I dispute that Haskell or Erlang are better suited for the purpose. And good luck finding Haskell and Erlang developers.

> This isn't a very convincing argument for Go.

I disagree.

> And good luck finding Haskell and Erlang developers.

Unless you need a massive number of developers, or you're located out in the middle of nowhere, it really shouldn't be too difficult.

I disagree.

Have you tried hiring Erlang or Haskell developers? It's not like they don't exist. In fact, there are likely many developers that would love to take an Erlang or Haskell job, but there aren't that many opportunities.

I don't dispute that they exist, I dispute the economics of finding them compared to finding or training new Go developers. Frankly, no one is going to replace their entire team and start a hiring campaign because Haskell or Erlang (arguably) make concurrency slightly easier than Go.

You would be surprised by the result. Economically it make sense. And i would argue that production ready Elixir/erlang is easier to teach than production ready Go.

Still, I'm fairly risk averse. I'll wait for the inevitable explosion of Erlang/etc shops to take off before I jump on board.

It happened. But well. Do as you want. It is your project :)

C++17 gives you async/await, coroutines and parallel algorithms.

Right, but this is still a far cry from Go's runtime/scheduler. In particular, the Go runtime completely handles threading and async I/O for me. I'm not sure what C++17 coroutines look like, but I don't even have to explicitly yield (which is the case in other C++ coroutine libraries).

Just like any other async/await model.

Also you don't need explicit yield on task runtimes like HPX.

> Just like any other async/await model.

I don't see how Go bears any resemblance to an async/await model. Did I misinterpret your statement?

> Also you don't need explicit yield on task runtimes like HPX.

I don't dispute that it's hypothetically possible to bolt enough things onto C++ to make it behave like Go, but I seriously doubt it's a viable solution. I would sincerely love to know if anyone has done all of this and is using it in production.

Async/await model is nothing more than a state machine over coroutine.

Goroutines are coroutines.

On the async/await model there are two approaches.

1 - The compiler takes care of the scheduling of the coroutines among the threads on the task pool, like C# 5.0 introduced.

2 - The compiler maps async/await into intrisics that know magic functions on the handles that represent tasks managed by the thread pool. This is called generalized async/await and is how C++17 will do it, and also how the C# model will evolve on C# 7.0

So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible to have control how the scheduling actually takes place among co-routines.

Granted Go's model is easier to understand and might be enough for many people, but it isn't a solution for all types of concurrency problems.

> Goroutines are coroutines.

Traditionally, "coroutine" has been used to refer to a userspace concurrency unit that is not multiplexed and which requires explicit yielding. Mostly I'm grumpy about broadening a previously precise definition.

> So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible to have control how the scheduling actually takes place among co-routines. Granted Go's model is easier to understand and might be enough for many people, but it isn't a solution for all types of concurrency problems.

Not having to control your own scheduling is the selling point of Go's concurrency model. Besides, Go does offer (at least some) control over scheduling via the runtime library. I've never had to use this in practice, and I can't imagine a scenario that would require nuanced control. I don't think async/await are the worst things, but I still prefer Go's runtime at least for the problems I have to solve.

So what would you call coroutines that multiplex at API calls like NT fibers, or many green threads libraries.

Or for that matter, coroutines on Active Oberon, which are just multiplexed as in Go.

I would call them fibers and green threads, respectively. No idea about Active Oberon.

What about http://libmill.org ? There are also numerous other programming environments with similar constructs.

Not cross platform last I checked.

I guess no Windows support could be a dealbreaker, but it's definitely "cross-platform" in several senses.

That isn't cross-platform in the senses I care about. I'm sure libmill is great and I wish it the best.

It's not that go can do things other language can't . It's the combination of keeping the language simple and gofmt means I can read anyone's code and understand it. I've been doing this for 25 years and that has never been true for me with any other language.

The real benefits for me with go are

Tooling. Gofmt, godef, etc make using emacs a dream.

Extensive stdlib. I pull in exactly two small libraries to build a very large web app: odbc, gorilla mux. Everything is baked in: http server, templating, compression, database

Cross compiling, being able to build a Windows exe in my Mac for deployment is awesome

Fast compilation.

Interfaces are a key concept and used everywhere to great effect in the std library

Of course there is almost nothing, which you cannot possibly do in any other language. The question is, at which effort and the resulting program quality. Go gives you strict (vs C) static type checking. Its local type inferencing saves you a lot of typing (as in keyboard) and makes the code concise and thus readable. It has a proper package system and very fast compile times (for larger projects way faster than C and C++). It has a rather rich standard library, it has a great GC which gets even better in 1.8 (100 microsecond stop times).