The problem with this approach is that as soon as you need to call out to a library written in a different language, it has no understanding of your lightweight green threads - precisely because it is currently a language/VM abstraction, not an OS abstraction, so everyone rolls their own. Furthermore, existing languages (notably, C) produce a legacy burden that'll remain even once OSes do start to add such threads.

For what it's worth, Win32 has offered a kind of green thread (fibers) for a very long time. Adoption has been minimal, even for other Microsoft products (e.g. .NET doesn't really support them properly).

I haven't done Erlang, but in my experience Golang has much the same problems as 1) so I'm not sure I'd agree. +1 to lightweight threads, tho.

Phoenix/Elixir can handle 2 million websocket connections on a single box. I would agree myself :)

http://www.phoenixframework.org/blog/the-road-to-2-million-w...

Wouldn't you need something like 40 NICs to do that?

I believe you are referring to running out of ports, as 65k available ports * 40 ~= 2M.

The limitation is actually on a quad tuple: {src_ip, src_port, dest_ip, dest_port}

As such, the actual limit is outrageously high and isn't really a problem. Interestingly enough, the referenced Phoenix benchmark overlooked the dest component and hit a limit as they had only 40 or so machines to use in the test. Had they used multiple ips on the server it would have given them a lot more breathing room.

EDIT: Multiple IPs != Multiple NICs. You can assign multiple IPs to a single physical interface. Also, they could have used multiple ports to accomplish the same effect.

Good to know. I thought you were always limited by the outgoing port range to 65k - (used ports) good to know.

So they were limited by the testing cluster or the tested server?

They were limited by the testing cluster, but it was pointed out to them after the fact that they could have used multiple IPs or multiple ports on the tested server to go even higher.