nobody trusts AI agents, that's why they are put in a harness. It's just that I additionally belong to the people who don't trust AI agents to always adhere to harnesses either.
true, but you'd be wrong to assume that Germans only compound words if both parts are nouns, e.g. "Gehweg" (walk way) and "Springseil" (jump rope) use the base of a verb.
We do actually have "Kochwasser" ("kochen" means "to cook", "kochend" means "boiling") but that's not boiling water ("kochendes Wasser") but for water used for cooking.
Rich Errors look promising to me, but what about interop with Java?
What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError?
Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type, can it??
Kotlin folks seem to mostly care about Java as bootstrap to their own ecosystem.
The anti-Java bias, against the platform that made it possible in first place and got JetBrains a business, is quite strong on Android, fostered by the team own attitude usually using legacy Java samples vs Kotlin.
This is needlessly divisive. JetBrains does not owe two-way interop to the Java ecosystem.
There are many Kotlin features that do not have clean interop with Java; Compose, coroutines, and value classes come to mind. And it turns out that this mostly benefits Java, because these features are not built with the kind of engineering rigor that Java language features enjoy, and some of these features would behave way better with support in the VM anyway.
Where it makes sense, they are already moving closer to Java/JVM-native feature implementations; for example, data classes already have two-way support via records, and value classes are almost there (waiting on Valhalla GA).
Besides, wouldn't you want this stuff represented in the Java type system anyway? Otherwise you get the Lombok problem, where you have this build dependency that refuses to go away and becomes a de facto part of the language. Result<T, E> is not quite the same as rich errors which explicitly are not representable by user types.
I know it is divisive, yet many Kotlin folks don't appreciate the platform that makes their ecosystem possible in first place.
From all the JVM guest languages, possibly fostered by Android team, they are the most anti-Java ecosystem.
Clojure folks appreciate being a hosted language, Scala is kind of they would rather have Haskell but still JVM is kind of cool, Groovy was usually a way to script applications.
Kotlin, well those behave as if ever the JVM would be one day rewriten in Kotlin, they have Android for that.
The features you mention will never be supported in Android by the way, at least I don't believe Google will ever bother to do so.
I view the relationship between Kotlin and Java like that between C++ and C.
The two-way interop is one of Kotlin's advantages as it makes porting code from Java to Kotlin easier, or using existing Java libraries. For example, you don't have/need something like Scala's `asJava` and `asScala` mappers as the language/standard library does that mapping for you.
The interop isn't always perfect or clean due to the differences in the languages. But that's similar to writing virtual function tables in C -- you can do it, and have interop between C and C++ (such as with COM) but you often end up exposing internal details.
Android folks have good reason to have anti-Java bias. Their bias, as it happens, is against old Java, which they are constrained to use as fallout from the Oracle lawsuits of yore. Kotlin breathed new life into Android in a meaningful way.
On backend teams, I've not personally encountered much anti-JVM bias - people seem to love the platform, but not necessarily the language.
(yes I know there's desugaring that brings a little bit of contemporary Java to Android by compiling new constructs into older bytecode, but it's piecemeal and not a general solution)
They cherry pick whatever they feel like from OpenJDK.
And even though Oracle was right, given that Android is Google's J++, in this case they had better luck than Microsoft.
They don't take more from OpenJDK because then their anti-Java narrative doesn't work out.
But there is some schadenfreund, to keep Kotlin compatibility story relevant they are nonetheless obligated to keep up with is mostly used on Maven Central, thus the updates up to Java 17 subset.
Maybe I'm wrong about the state of Java in Android today - it's been a few years since I did that work full-time. But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! The embrace of a non-Java language was grassroots and genuine; Google's adoption came several years later.
J++ though, now that is a blast from the past! I think I still have a J# book from my student days, somewhere :)
ART is updatable via PlayStore since Android 12, however in 2026 the latest is a Java 17 subset, while the latest LTS is Java 25.
Kotlin only worked properly on Android after some folks pushed it from inside, and then they used Java 6 vs Kotlin samples to advocate for it.
In 2015 the latest Java version was 8, which never was properly supported on Android, the community had to come up with RetroLambda, before Google created desugaring support, think Babel but for Java.
Naturally it also meant that the performance of Java 8 features wasn't the same, e.g. lambdas make use of invokedynamic on the JVM, on Android they used to be rewriten into nested classes.
Even today, although Android documentation has Java and Kotlin tabs for code snippets, the Java ones are hardly taking advantage of modern features.
Naturally who learns Java on Android gets an adulterated view on the matter.
> But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7!
n=1 but i was there with android studio v0.01 (or thereabouts) using kotlin for a production app cause i was so sick of old-java + eclipse... google was asleep at the wheele imo and android development would be nowhere near where it is today without jetbrains
Compared to Apple and Microsoft, Android development is mostly outsourced.
None of the development environments is from Google, none of the languages as well, or the build tools for app developers (Internally they use Bazel and Soong).
Naturally having gone into bed with JetBrains for the IDE, after leaving NDK users without IDE tooling for almost two years during the IDE transition, the deal was in place to push Kotlin as well.
I am surprised Google hasn't yet bought JetBrains.
by default it'll be exposed as a `java.lang.Object` and they've thought about using compiler plugins to generate methods returning `Optional<>` or `Result<>` instead
thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D
They only care about Java -> Kotlin integration. Not the other way around. It has been like this for a long time. Looks like an extractive relationship to me to be frank.
Anyone who is writing Kotlin libraries to be consumed by Java code is going to either avoid this feature or write wrapper functions for better Java interop. There is no reason to accuse language designers of lock-in by designing features that don't have a clear equivalent on every possible foreign interop target.
Kotlin does have interop with Java, but is limited by either the features not existing in Java (non-nullable types) or behave differently in Java (records, etc.).
You have to explicitly annotate that a Kotlin data class is a Java record due to the limitations Java has on records compared to data classes [1]. This is similar to adding nullable/not-null annotations in Java that are mapped to Kotlin's nullable/non-nullable types.
Where there is a clean 1-1 mapping and you are targeting the appropriate version of Java, the Kotlin compiler will emit the appropriate Java bytecode.
technically, Kotlin can use VirtualThreads like it can use any other Java Api
(when being compiled to JVM bytecode).[1]
If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads.
So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines).
What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions!
My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)
I really like languages with non-/nullable types like Kotlin and Rust! I used to work with Java for over a decade and therefore used to code very defensively against NullPointerException and now (with Kotlin) I just don't have to do this anymore.
That being said there are two possible sources of nullpointers: from inside your program or from outside (e.g. the json your server got send wasn't fully initialized). The majority of NullPointers come from outside in my experience. Nullpointers from within you have to fix mostly once. but there's no end to what data send to you from outside your control can be missing.
Of course you still have to validate/parse outside data when using Kotlin but since the type system then carries on which data has been validated, you can drop the defensive mindset that was appropriate in Java.
So if you have a self-contained, non-safety critical project and want to use/try out an arena-allocated memory approach using Odin seems fine (e.g. looking at you: "raytracing in a weekend").
So yeah, I think there's a niche of projects where the possibility of null pointers isn't a huge deal.
None of my work-related projects fall in that category though :D
I agree, i started with (scope) blocks in Rust, but keep the habit in Kotlin win the run - scope-function. Since run takes no arguments, it feels like the closest equivalent to Rust scopes (compared to other Korlin scope functions, which also keep their local variables from polluting the rest of the function body).
this is exactly about what is legal or not.
If I remember correctly in Germany there's a distinction about people being the focus of a photograph or people in the background. You can e.g. publish a picture of a public place without asking everybody on that place for their consent.
Another corner case would be filming police brutality. What if the police officers in question wouldn't like to be photographed being brutal!?
Local laws do apply.
This law badly needs to be updated to account for the fact that photo/video resolutions have massively increased since it was written, and "not the focus of a picture" is no longer enough to prevent you from being identified/tracked in the picture, which was the original intent.
Have you seen the cameras on cell phones compared to the cameras of yesterday? Resolutions are up but faked through software. A 640 picture from 2004 can be enlarged with clearer detail compared to a 2000px of today always looking sharp but never truly capturing a clear picture.
