3 ms·

> unless you're trying to run lots of threads Well this is exactly the design point. The authors want to promote a coding style where spawning a new thread is

> unless you're trying to run lots of threads Well this is exactly the design point. The authors want to promote a coding style where spawning a new thread is ultra-cheap, possibly at a ratio of very few IO calls per virtual thread. The ideal application would be WhatsApp's use of Erlang [1][2]: 2.8M active connections per server (in 2012! 100GB RAM servers), each of them mostly idle with 200k msgs/sec. All of this while keeping the threading model, keeping your stacks intact for debugging, and possibly a hierarchy of threads where you can kill a whole branch and hot-reload it with new code. (which is a thing that's not easy to do with reactive programming / async await) [1] http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi... [2] https://web.archive.org/web/20221220020352/http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf https://web.archive.org/web/20221220020352/http://www.erlang...

silvestrov 4y ago
> 2.8M active connections per server I think this is a use-case best left for nginx and other proxies written i C. Java should be easy to use. Leave weird specialcase programming to special tools. Don't try to make java solve all problems. Java nio became a monster of complexity which made implementing an http server much more complex that it should be.
- gpderetta 4y ago
  With modern hardware 2.8M doesn't seem a particularly large number. Modern Java VMs are pretty efficient (more so after project Loom), so I don't see why Java wouldn't be appropriate for this use case. In fact efficient virtual threads would allow avoiding nio and provide a fast and sane blocking interface. Note: I say this as a C++ programmer.
  - deleted 4y ago
    [deleted]
  - xxs 4y ago
    Having that many connections requires tons of buffering and effectively manual scheduling (or clients can experience latency issues). At the very least non-blocking io allows to tune the scheduling depending on the clients behavior and importance. Personal experience: tons of java nio and lock-free structures.
- duped 4y ago
  Rightly or wrongly, that's exactly what Java is designed for. Write once, run anywhere. It's not just for HTTP servers and web services.
deleted 4y ago
[deleted]
fulafel 4y ago
To expand the quote: >> Virtual threads don't seem like a worthwhile complexity tradeoff unless you're trying to run lots of threads in 32-bit address space Bolting M:N threads onto JVM runtime in the hope it will enable people to program the JVM like Erlang (without the rest of the Erlang feature set that actually make it good) still seems to me a clear cut case of "not a worthwhile complexity tradeoff". The added JVM implementation complexity and maintainance burden would seem to be pretty heavy for something like this.

silvestrov 4y ago

> 2.8M active connections per server I think this is a use-case best left for nginx and other proxies written i C. Java should be easy to use. Leave weird specialcase programming to special tools. Don't try to make java solve all problems. Java nio became a monster of complexity which made implementing an http server much more complex that it should be.

gpderetta 4y ago
With modern hardware 2.8M doesn't seem a particularly large number. Modern Java VMs are pretty efficient (more so after project Loom), so I don't see why Java wouldn't be appropriate for this use case. In fact efficient virtual threads would allow avoiding nio and provide a fast and sane blocking interface. Note: I say this as a C++ programmer.
- deleted 4y ago
  [deleted]
- xxs 4y ago
  Having that many connections requires tons of buffering and effectively manual scheduling (or clients can experience latency issues). At the very least non-blocking io allows to tune the scheduling depending on the clients behavior and importance. Personal experience: tons of java nio and lock-free structures.
duped 4y ago
Rightly or wrongly, that's exactly what Java is designed for. Write once, run anywhere. It's not just for HTTP servers and web services.

deleted 4y ago

[deleted]

fulafel 4y ago

To expand the quote: >> Virtual threads don't seem like a worthwhile complexity tradeoff unless you're trying to run lots of threads in 32-bit address space Bolting M:N threads onto JVM runtime in the hope it will enable people to program the JVM like Erlang (without the rest of the Erlang feature set that actually make it good) still seems to me a clear cut case of "not a worthwhile complexity tradeoff". The added JVM implementation complexity and maintainance burden would seem to be pretty heavy for something like this.