3 ms·

Recently I've been doing a bit of research on what tech stack to choose for my next project. I'm a long time Java dev and been doing JS/TypeScript dev the last

by campers 11y ago

Recently I've been doing a bit of research on what tech stack to choose for my next project. I'm a long time Java dev and been doing JS/TypeScript dev the last year. I'd been deciding with a newer Java/JVM stack or node.js/TS. There's a library that fixes the sync I/O issue in Java call Quasar which implements lightweight threads called Fibers. I remember seeing it a while ago and thought it was pretty interesting and it seems reasonably mature now. One of the nicest things about it is you can get async IO with a sync programming model. So no callbacks and chaining of promises. I'll probably start with Java 8 but the other JVM language I quite like it Kotlin, which has a similar style to TypeScript in some ways, and is designed for Java interop. Kotlin + Quasar fibers seems like a pretty nice combo on the JVM. http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/ http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/ http://blog.paralleluniverse.co/2015/08/28/quasar-0.7.3-comsat-0.5.0/ http://blog.paralleluniverse.co/2015/08/28/quasar-0.7.3-coms...

nothrabannosir 11y ago
The problem is not the lack of async IO, but the existence of sync IO. As long as sync IO is a possibility, it will spread through your program like a cancer. Even without using it yourself, all your libs will. Does Quasar address this? Edit: just to clarify: it's not as bad as I make it sound. Java may still be the best tool for your project. It's definitely got a great VM and good libs. If it makes sense, use it.
- campers 11y ago
  Sync I/O API's are still an issue, the main one being JDBC. The approach with Quasar is to have a dedicate thread pool for the JDBC calls, which in that case isn't necessarily too bad as you don't want to overload your database. Comsat is the companion project which provides the quasar fiber integration to common libraries/services (http, servlet, db etc) which gives you the nice synchronous programming model (via bytecode instrumentation) with the async/light thread scalability. So your incoming servlet request would use the async servlet API integration to move the execution to a fiber. Then calls to an external http service, out-of-process cache, files, NoSQL db etc would all happen within the fibers. Its mainly the JDBC that requires a pool of normal threads. I've only just decided this is what I want to use next, so I'll be able to tell from experience over the coming months!

by campers 11y ago

nothrabannosir 11y ago

The problem is not the lack of async IO, but the existence of sync IO. As long as sync IO is a possibility, it will spread through your program like a cancer. Even without using it yourself, all your libs will. Does Quasar address this? Edit: just to clarify: it's not as bad as I make it sound. Java may still be the best tool for your project. It's definitely got a great VM and good libs. If it makes sense, use it.

campers 11y ago
Sync I/O API's are still an issue, the main one being JDBC. The approach with Quasar is to have a dedicate thread pool for the JDBC calls, which in that case isn't necessarily too bad as you don't want to overload your database. Comsat is the companion project which provides the quasar fiber integration to common libraries/services (http, servlet, db etc) which gives you the nice synchronous programming model (via bytecode instrumentation) with the async/light thread scalability. So your incoming servlet request would use the async servlet API integration to move the execution to a fiber. Then calls to an external http service, out-of-process cache, files, NoSQL db etc would all happen within the fibers. Its mainly the JDBC that requires a pool of normal threads. I've only just decided this is what I want to use next, so I'll be able to tell from experience over the coming months!