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, 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 great though, especially Elixir, but for some use cases Go is better.

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

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.

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.

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

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.

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.

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.

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