4 ms·

Kotlin seems finally like a language designed by people who actually develop in it. OTOH Oracle people seem to always focus on the platform issues - green thre

Kotlin seems finally like a language designed by people who actually develop in it. OTOH Oracle people seem to always focus on the platform issues - green threads is the next big thing, but it doesn't actually affect 99% of developers since Java's threading model is just fine for most business applications. Yet things like missing ability to reasonably express non-nullability (and the resulting NPEs) hit me every single day, but for Oracle it's apparently not an interesting enough to work on.

thu2111 6y ago
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_rationalist 6y ago
Oracle pushing the boundaries of the platform is actually awesome because Kotlin can reap all those benefits almost for free
- pjmlp 6y ago
  Actually no, due to Android.
  - The_rationalist 6y ago
    Kotlin expose some modern JVM only features it's just that they are optin
    - pjmlp 6y ago
      Indeed, the typical example why guest languages lose to platform languages as the platform evolves. As the schism grows, library authors get faced with the decision how much they can actually use from the underlying platform.
pjmlp 6y ago
Great now let them bring the Kotlin Virtual Machine. Ah, that is what Google is doing for them.
- The_Colonel 6y ago
  No need for this, there's bunch of existing virtual machines. JVM is pretty nice actually.
  - pjmlp 6y ago
    Sure there is, Kotlin users typically bash Java and how much better it is, so I am waiting for JetBrains to release KVM, Kotlin/Native so far loses in all frontends against AOT Java based toolchains.
    - MaxBarraclough 6y ago
      > Kotlin users typically bash Java You mean the Java programming language, or the Java Virtual Machine?
      - pjmlp 6y ago
        Both, given that 80% of most JVM implementations are Java as well.
        MaxBarraclough 6y ago
        That doesn't sound right. Why would Kotlin programmers dislike the JVM platform just because it tends to be implemented in Java (and C++)? The Python and Lua interpreters are written in C. V8 is written in C++, SpiderMonkey in C/C++. The Rust compiler backend is LLVM, written in C++. The GNAT Ada compiler is powered by GCC, written in C. So what? These implementations work fine. Directly competing with the JVM makes little sense. Countless millions of dollars of effort have been poured into OpenJDK.
        6y ago
apta 6y ago
A couple of options for handling nulls: * https://checkerframework.org/ * https://github.com/uber/NullAway

thu2111 6y ago

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_rationalist 6y ago

Oracle pushing the boundaries of the platform is actually awesome because Kotlin can reap all those benefits almost for free

pjmlp 6y ago
Actually no, due to Android.
- The_rationalist 6y ago
  Kotlin expose some modern JVM only features it's just that they are optin
  - pjmlp 6y ago
    Indeed, the typical example why guest languages lose to platform languages as the platform evolves. As the schism grows, library authors get faced with the decision how much they can actually use from the underlying platform.

pjmlp 6y ago

Great now let them bring the Kotlin Virtual Machine. Ah, that is what Google is doing for them.

The_Colonel 6y ago
No need for this, there's bunch of existing virtual machines. JVM is pretty nice actually.
- pjmlp 6y ago
  Sure there is, Kotlin users typically bash Java and how much better it is, so I am waiting for JetBrains to release KVM, Kotlin/Native so far loses in all frontends against AOT Java based toolchains.
  - MaxBarraclough 6y ago
    > Kotlin users typically bash Java You mean the Java programming language, or the Java Virtual Machine?
    - pjmlp 6y ago
      Both, given that 80% of most JVM implementations are Java as well.
      - MaxBarraclough 6y ago
        That doesn't sound right. Why would Kotlin programmers dislike the JVM platform just because it tends to be implemented in Java (and C++)? The Python and Lua interpreters are written in C. V8 is written in C++, SpiderMonkey in C/C++. The Rust compiler backend is LLVM, written in C++. The GNAT Ada compiler is powered by GCC, written in C. So what? These implementations work fine. Directly competing with the JVM makes little sense. Countless millions of dollars of effort have been poured into OpenJDK.
        6y ago

apta 6y ago

A couple of options for handling nulls: * https://checkerframework.org/ * https://github.com/uber/NullAway