The Java interop compromise is probably the biggest weakness of the proposal - it works beautifully within Kotlin but degrades at boundaries. This is similar to how Kotlin's nullable types (String?) become platform types in Java.

I think it's good nonetheless to add stuff to Kotlin that won't translate 1:1 to Java, both because Java is evolving but also because Kotlin is used in "Native" (non-JVM) contexts as well (not extensively, but hopefully that'll change).

The ship has sailed the moment Kotlin believed it could break away from the JVM ecosystem. And for a good reason, it would be just slowly consumed by the progress of Java.

That is always the gotcha with guest languages.

C++ cannot get away from C, Typescript cannot get away from JavaScript, and so forth.

That is more interoperability than guest language situation. I don’t think c++ is a c guest. Ts has a different approach to the js self.

C++ started as a C macro preprocessor, designed to work as C in UNIX, and by CFront 2.0 there was already too much compatibility to throw away.

Ts is basically a linter, everything else is JS.

c++ bootstrapping as a transpiler back when it was a 1 man show is hardly where it’s at today. The point about self handling in ts should demonstrate there is more than just strip the types going on

There is the whole fit into the same UNIX compiler toolchain as C, without additional changes to the linker, include files, object and archive files.

Oh like how gnu compiler includes an ada compiler ? Or the C++ name mangling ?

Obviously there a common heritage and the shared ancestor is c.

C++ name mangling was exactly designed to be able to link C++ code with a standard UNIX linker that only knows C.

GNAT has zero compatibility with C source, doesn't even make sense.

I'm impressed. Makes me want to learn assembly!