I guess this will be killed soon enough, like so many Google projects.

I too adopted Scala in 2014 and was really satisfied with FP side and how it all was tied with JVM. Honestly I always felt that JVM is a nice platform with a horribly verbose “assembly” language that is Java.

Fast forward to around 2020 and I had to organize a team to build search engine in JVM. Given how hard it is to find decent Scala developer I surrendered and did this project in Kotlin. Java devs easily pick up and write sensibly FP-style even code, and builtin coroutines are cool. Even though I had to open up the internals of coroutines to get tracing to work they felt a very welcome change compared to say monadic explicit async.

So for me Kotlin is kind of watered down Scala for typical Java folks and I could tolerate it compared to perspective of writing plain Java.

Why not full VM with JIT? Seems much easier and more compatible with apps out there.

You can also run the full JVM and in fact I'd imagine that's how most of our JVM users actually use it today.

Because the JVM is fairly dynamic so it becomes hard to know which part to prune

Used cucumber as living specification for our search engine. Sooner or later we realized it was just matching a list of expected JSONs with a bunch of awkward Given, And Then mixed in. Scraped that stuff for our own Kotlin DSL, made the whole thing more flexible and faster to boot.

I recall the Zookeeper paper from Yahoo scientist which basically details a more useful version of Google’s chubby. I find reliability and design of Zookeeper fascinating these days cool kids use etcd mostly because of relatively complex protocol of Zookeeper (there is a few implementations but they lack the polish of Java client).

There is a drop-in, protocol-compatible replacement for ZooKeeper - ClickHouse Keeper: https://clickhouse.com/clickhouse/keeper

Many applications depend on ZooKeeper's data model and client libraries, and can't switch to etcd. Things like watches and ephemeral nodes are different there.

iirc problem of the zookeeper was that it was a chunky java application. etcd is tiny go binary. so there is more to it than just complexity of the protocol itself.

I recall playing Warcraft I with my friend over null modem. Kind of boutique LAN party.

Think of page tables this is essentially a table of tables of tables. I also was meh on triple pointers until I found this use case.

Yes, but the third level isn't a "triple pointer", but a pointer to the next level. A page table level isn't just a pointer-to-a-pointer but carries information. So a three-level table doesn't have `void***` in the top level, but `PageTableLevel2*`.

As colejohnson66 noted. I would use typedef table, typedef page, etc. A void* is a pointer to the void. A page table is a table of pages.

I think there was a discussion to add SuperStack a threadlocal buffer that will be used for arena style allocation back in 2010-2011. While std wont have it I see no problem implementing one yourself.

Patching the binary is an option, though it’s tricky I would attempt it anyway.

Alas an ios app, which is in the app store.

It was a "nice feature" of an older unrelated system, we're going through a procurement to replace it, as patching a binary is fine for me, but not really a supportable solution at an enterprise level :D

Or zookeeper for that matter.