In effect this is still Ethernet over TCP, but other than that it's a cool idea. Now if only NATS would support SCTP...

Agree. I would really like to hear what is the upside / sales pitch of NATS compared to an Erlang server (that, BTW, supports SCTP out of the box).

NATS can saturate a network port with hundreds of thousands of messages/second with minimal impact on CPU, it scales linearly with cores, and it has minimal/zero effort fail-over. Whether across large geographic boundaries (ie: AWS cross-region) or in the same rack, NATS clustering is reliable and definitely speedy.

Well said; the other project involving NATS from the Rapidloop team (gRPC over NATS essentially) mentions some benefits as they see it which are what you've pointed out: https://github.com/rapidloop/nrpc

Thanks!

Developer creates alpha /pet project for fun and learning and HN commenters complain it doesn’t do enough... sheesh.

I don't see any trace of complaint; did he edit his post?

No actually I think I was quick to judge. My critique is wrong.

Eh, easy mistake. Text lacks a lot of nonverbal context.

What about quic?

Ethernet or raw IP over TCP are slow (without some really creative hacks involving multiple TCP links) due to the double ACK problem. Adding UDP would probably not be hard.

Also check out zerotier. It works really well, and routes traffic through the local lan if available. It also supports other protocols than ip.

"... only works on Linux."

"Multicast is not supported."

I seem to recall other L2 overlay projects, UDP-based, that are both portable to other OS (subject to TAP requirement) and have no problem with multicast.

Curious: What causes these limitations with NATS?

NATS is just a message broker, and runs wherever Go runs. The limitations are in this project. It's a 105-line proof of concept, clearly the author didn't bother making it portable.