blog-2024-01-11

# daily random links

* "[epoll]: The API that powers the modern internet"  
  https://darkcoding.net/software/epoll-the-api-that-powers-the-modern-internet/  

  * "Comparison of [Rust] async and [Linux] thread context switch time and memory use" by [Jim_Blandy]  
    https://github.com/jimblandy/context-switch

* conditional [git] configuration  
  https://blog.scottlowe.org/2023/12/15/conditional-git-configuration/  
  i use this to manage profiles between different different roles, each of of which has a different project directory

* "Perhaps Emotional Dependence on Celebrities Has Gone Too Far" by [Freddie_deBoer]  
  https://freddiedeboer.substack.com/p/perhaps-emotional-dependence-on-celebrities

* "‘Magical’ Error Correction Scheme Proved Inherently Inefficient"  
  https://www.quantamagazine.org/magical-error-correction-scheme-proved-inherently-inefficient-20240109/

* "Database-Instance using half of available CPU cores" [dba] [StackExchange]  
  https://dba.stackexchange.com/questions/334701/database-instance-using-half-of-available-cpu-cores

* Song: Frazey Ford - Done  
  https://www.youtube.com/watch?v=PXRrySTujn8

# The golden age of Kotlin and its uncertain future

read: https://shiftmag.dev/kotlin-vs-java-2392/ ^[HN](https://news.ycombinator.com/item?id=38948259)^

there have been several languages targeted at the [JVM] attempting to improve developer ergonomics ([groovy], [scala], [clojure], ...). 

the author argues that [java] tends to wait and see and then cherry pick the features that prove themselves valuable.

1. as java does have  more resources it'll always have better tooling. 
2. java itself is too big to die, mostly due to corporations and tons of legacy code.

the upstart projects usually have less manpower to innovate much beyond their initial set of foundational ideas that made them take off. 
after a while, java tends to integrate the juiciest bits, diminishing the unique selling point of its competitors.

does the same apply to [kotlin]? has kotlin's downfall already begun? imo, no / not yet.

for one, there's been _massive_ buy-in from google for the [Android] platform. this alone significantly changes the game.

then kotlin has corporate backing from [Jet_Brains], and, via android, indirectly also from [Google].

and lastly, in my personal opinion, kotlin has a few killer features that aren't present in java and would be very hard to steal, as 
they'd fundamentally change java's characteristics and compatibility to earlier versions.

* nullability handling; compared to kotlin's `?` the `Optional` wrapper feels clunky and, more important, it's not enforced. if it's not enforced by
the type system, guarantees are weak and developer adoption is leaky.

* everything is an expression: no idea whether java could implement this without breaking compatibility. this and implicit returns are an improvement on the scale of
anonymous objects vs. `lambda`s.

* scope function blocks: may be possible in java, but i see no attempts to emulate them.

* also kotlin is similar enough to java to have a very low barrier to entry for new developers. 

as for [coroutines] vs. [virtual_threads]: kotlin did profit from virtual threads for free. that's not an argument for java, it's one for kotlin.

all in all, i see the authors point, but i don't think we've reached the point of kotlins decline for at least a few more years.

tags: [kotlin] [java] [IntelliJ_IDEA]

edited by: stefs at Friday, January 12, 2024, 9:17:08 AM Central European Standard Time


view