3 ms·

Virtual threads will probably have a lot more impact than you imagine. Basically any server gets written in weird ways currently due to the need to conserve thr

Virtual threads will probably have a lot more impact than you imagine. Basically any server gets written in weird ways currently due to the need to conserve threads, or belief that you might need to in future. Blocking IO is just simpler to program but nobody does it anymore for that reason. The amount of code that will become "tech debt" the moment Loom becomes widely available is very large. Oracle are improving the Java language, but of course Kotlin could go much faster as a greenfield project with no community to involve or please. It's got a long way to go to match Kotlin. That said, Kotlin the language is now stable for quite some time and isn't really changing, so it's a relatively static target.

The_Colonel 6y ago
> The amount of code that will become "tech debt" the moment Loom becomes widely available is very large. 1) As I understand green threads will not require vastly different programming model (no colored functions). So my code can stay mostly the same as it is. 2) My microservices are working just fine now, without performance/scalability issues (certainly nothing related to thread count limit) so why would they turn into tech debt? > That said, Kotlin the language is now stable for quite some time and isn't really changing, so it's a relatively static target. Yes, but Java is not moving towards it in some respects at all. There's no effort to tackle the nullability problem for example.
- thu2111 6y ago
  Your code can stay as it is, yes. Loom is fully backwards compatible. By tech debt I mean, it will become code that is needlessly complex and hard to maintain for what it does and thus become a candidate for simplifications and refactorings. I didn't mean it'll stop working.
  - The_Colonel 6y ago
    It's all too abstract for me. Let's assume typical spring microservice - controller layer, service layer, perhaps some persistence or integration with other microservices. What parts of such microservice will become harder to maintain compared to Loom variant?
    - gravypod 6y ago
      If you're using libraries for everything, nothing. If you need to implement network IO or something, you no longer need to use NIO to get NIO performance. You can just do blocking reads and writes in your threadlet and get the same performance with entirely serial code execution.
      - The_Colonel 6y ago
        But that just means it doesn't really bring that much for 99% of projects. The only time I was writing NIO code was during some Java certification ...
    - vips7L 6y ago
      Have you looked at the maintainability nightmares that are the reactive model and applications based upon RxJava? Those types of applications are leagues harder to maintain compared to a virtual thread model.
    - thu2111 6y ago
      If you're already writing all callouts from your controllers in a blocking manner then nothing. Because async IO is a pain in the rear lots of libraries try to hide it from you in various ways. However if you're using e.g. pure Java JDBC / SQL drivers, then you should be able to get higher throughput from your web servers and can maybe shrink your server footprint. However, lots of people don't write code that is just HTTP servers ("microservices"). Also, consider that when it gets easier to write server frameworks there'll be more competition and they'll move faster. So maybe Spring Boot won't seem so attractive in future as someone will have developed something better.

The_Colonel 6y ago

> The amount of code that will become "tech debt" the moment Loom becomes widely available is very large. 1) As I understand green threads will not require vastly different programming model (no colored functions). So my code can stay mostly the same as it is. 2) My microservices are working just fine now, without performance/scalability issues (certainly nothing related to thread count limit) so why would they turn into tech debt? > That said, Kotlin the language is now stable for quite some time and isn't really changing, so it's a relatively static target. Yes, but Java is not moving towards it in some respects at all. There's no effort to tackle the nullability problem for example.

thu2111 6y ago
Your code can stay as it is, yes. Loom is fully backwards compatible. By tech debt I mean, it will become code that is needlessly complex and hard to maintain for what it does and thus become a candidate for simplifications and refactorings. I didn't mean it'll stop working.
- The_Colonel 6y ago
  It's all too abstract for me. Let's assume typical spring microservice - controller layer, service layer, perhaps some persistence or integration with other microservices. What parts of such microservice will become harder to maintain compared to Loom variant?
  - gravypod 6y ago
    If you're using libraries for everything, nothing. If you need to implement network IO or something, you no longer need to use NIO to get NIO performance. You can just do blocking reads and writes in your threadlet and get the same performance with entirely serial code execution.
    - The_Colonel 6y ago
      But that just means it doesn't really bring that much for 99% of projects. The only time I was writing NIO code was during some Java certification ...
  - vips7L 6y ago
    Have you looked at the maintainability nightmares that are the reactive model and applications based upon RxJava? Those types of applications are leagues harder to maintain compared to a virtual thread model.
  - thu2111 6y ago
    If you're already writing all callouts from your controllers in a blocking manner then nothing. Because async IO is a pain in the rear lots of libraries try to hide it from you in various ways. However if you're using e.g. pure Java JDBC / SQL drivers, then you should be able to get higher throughput from your web servers and can maybe shrink your server footprint. However, lots of people don't write code that is just HTTP servers ("microservices"). Also, consider that when it gets easier to write server frameworks there'll be more competition and they'll move faster. So maybe Spring Boot won't seem so attractive in future as someone will have developed something better.