5 ms·
At it's base Kotlin is a nicer java. But it's much more. Simply looking at the syntax comparison is only half of the story. The focus at the recent conference w
by soulnothing 7y ago
At it's base Kotlin is a nicer java. But it's much more. Simply looking at the syntax comparison is only half of the story. The focus at the recent conference was multi platform and concurrency.
They are making concurrency a first class citizen. With items like Go channels, Observable etc. This is baked into the language. There are a number of new frameworks utilizing these patterns. Resulting in less code, and more performance. At the cost of sometimes more difficult debugging.
The bigger item to me is multi platform. I'm working on a micro orm. That reflects your schema automatically generating types for NodeJs, Native, and JVM(Graal/JDK). It can then be run on any of those platforms. An example is libpq for postgres allows streaming and observing rows on update. This is not in the DB libraries that I've seen yet. I can have an actor run natively on LLVM, talk back via grpc/rsocket/tcp/etc. To a JVM/JS service. All while adhering to the same interface / method description.
Besides that. There are scripts for kubernetes, react/angular/vue, etc. Dukat is coming to automatically convert ts.d files to kotlin description files. For me I can have one language, one IDE, for every part of my product. From deployment, back end, data handling, front end, and mobile.
- vips7L 7y agoI don't see how concurrency isn't a first class citizen in Java, especially compared to kotlin/native's concurrency package which is barely a package.
- fnord123 7y agoThread based concurrency where everything is blocking inside the thread is the first class citizen. If you want to move to a non blocking world, then you will suffer. Moving between Channel and Flow sucks. No async/await keywords like Python, C#, Rust so you have callback hell. try-with-resources doesn't work with async callbacks (i.e. thenApply, thenCompose, etc.). Also, JAX-WS standard doesn't currently support Channel or Publisher<ByteBuffer> for body types.
- apta 7y agoJava is getting green threads/fibers by means of project Loom. Arguably much more straightforward to use compared to async/await.
- ksec 7y agoSo when is this Project Loom set to arrive?
- fnord123 7y agoLiterally "when it's done". This is the answer given in talks by the developers working on it. But you have to understand that many many libraries are on Java 1.8 because that's what Android supports. Even when Loom arrives, many libraries won't use it but will rather continue to use threads.
- thu2111 7y agoBut that's the nice thing about Loom. The direction they're heading in is upgrading the existing Java threading APIs. Maybe not "new Thread() {}" but if you use ForkJoinPool, executors, etc then it should mostly all just work. That means it won't fork the ecosystem in the same way Kotlin coroutines do (coloured functions in new languages). And even better it won't fork the ecosystem across Android either. If you use constructs that don't automatically Loomify, you can just tweak them so they still work fine on Android but get the benefits of Loom too. BTW parts of Loom already shipped. On the other hand, outside of certain core libraries this won't matter much. You don't do a whole lot of scalable blocking IO on phones.
- fnord123 7y ago>Maybe not "new Thread() {}" but if you use ForkJoinPool, executors, etc then it should mostly all just work. Ah that's a nice way to do it. But then what happens to Channels? Are they cast aside so we go back to InputStream which blocks the fiber? > You don't do a whole lot of scalable blocking IO on phones. No but you can save a lot of memory, a lot of context switches, and CPU depending on the scenario.
- apta 7y agoJava is getting fibers (check out project Loom). They're supposed to provide the same level of debugability as regular multi-threaded code.