Many larger companies in The Netherlands have moved away from Scala and Java and use Kotlin now. The switching costs are neglegible and the benefits are big.
The problem with Kotlin is, you don’t want to go back to Java.
Hey. Do you folks have office in India or are you hiring remote for Kotlin? (esp. someone from Android bg but pretty decent at general Kotlin; and also at Java)
It could also be that there just isn’t enough demand for a non-blocking JDBC. For example, Postgresql server is not coping very well with lots of simultaneous connections, due to it’s (a.o.) process-per-connection model. From the client-side (JDBC), a small thread poool would be enough to max out the Postgresql server. And there is almost no benefit of using non-blocking vs a small thread pool.
I would argue the main benefit would be that the threadpool that the developer would create anyway would instead be created by the async database driver, which has more intimate knowledge about the server's capabilities. Maybe it knows the limits to the number of connections, or can do other smart optimizations. In any case, for the developer it would be a more streamlined experience, with less code needed, and better defaults.
I think we’re confusing async and non-blocking? Non-blocking is the part what makes virtual threads more efficient than threads. Async is the programming style; e.g. do things concurrently. Async can be implemented with threads or non-blocking, if the API supports it. I was merely arguing that a non-blocking JDBC has little merit as the connections to a DB are limited. Non-blocking APIs are only beneficial when there are lots, > 10k connections.
JDBC knows nothing about the amount of connections a server can handle, but to try so
many connections until it won’t connect any more.
| In any case, for the developer it would be a more streamlined experience, with less code needed, and better defaults.
I agree it would be best not to bother the dev with what is going on under the hood.
They indeed optimize thread context switching. Taking the thread on and off the CPU is becoming expensive when there are thousands of threads.
You are right that everything blocks, even when going to L1 cache you have to wait 1 nanoseconds. But blocking in this context means waiting for “real” IO like a network request or spinning disk access. Virtual threads take away the problem that the thread sits there doing nothing for a while as it is waiting for data, before it is context switched.
Virtual threads won’t improve CPU-bound blocking. There the thread is actually occupying the CPU, so there is no problem of the thread doing nothing as with IO-bound blocking.
For disk IO it’s faster, there are many benchmarks on the internet.
For network IO, it depends. Only two things make it theoretically faster than epoll; io_uring supports batching of requests, and you can save one sys call compared to epoll in an event loop. There some other things that could make it faster like SQPOLL, but this could also hurt performance.
I see an issue with a narrative but zero discussion at that link.
Furthermore, your io_uring benchmark being utilized in that issue isn't even batching CQE consumption. I've submitted a quick and dirty untested PR adding rudimentary batching at [0]. Frankly, what seems to be a constant din of poorly-written low-effort benchmarks portraying io_uring in a negative light vs. epoll is getting rather old.
The linked issue barely mentions frevib's echo server, and in the one place it does it's the fastest!
Further they show that performance improves when using io_uring for readiness polling but standard read/write calls to actually write - that suggests io_uring_for_each_cqe does not explain the cases where epoll is faster.
> I've submitted a quick and dirty untested PR
That's not improving the situation much then - surely any performance fix should come with at least a rudimentary benchmark?
Measuring IOPS of random, small reads (4kiB, O_DIRECT, single NVMe). (It's for optimising a database engine doing random lookups, but the benchmark is just random reads, no other logic.)
Just now I have tested 1,133 kIOPs with threads and 598 kIOPS with io_uring. The SQE queue depth for io_uring and max threads for thread test are set the same, 512.
I'd like to think this is due to a particularly well-optimised thread pool :-)
Kotlin is slighty better Java. No more getters, setters, hashcode and toString. Kotlin is also much better Java for asynchronous programming, null-safety, and functional programming. It’s modern Java.
Scala 3 introduces a number of simplifications. For example, typeclasses and other constructs are much easier with Scala 3. This said, Scala always included the idea of having a powerful type system. From this perspective, it can never be as simple as a language that doesn't have a comparatively powerful type system (or no static type system at all).
The philosophy behind Kotlin and Java really couldn't be more different. Go is much closer to a modern Java than Kotlin.
Kotlin does have some nice additions. But it is very much a kitchen sink language. I wish I could take some of those nicer additions and leave the sink.
If you are on another locale, search “ublock origin lite” with double quotes.