That is one of the reasons I dislike guest languages, the communities tend to have a culture of rebuilding the underlying stack, as if not appreciating that it is what allows their favourite language to exist in first place.
What is a "guest language", haven't heard this term used outside of GraalVM before?
From context, it's a language that uses the platform of a host?
IE, JVM languages like Kotlin/Scala/Clojure when Java was the initially intended one? Or CLR languages like VB/F# which are second-class in comparison to C#?
If it is this, the one interesting thing I have to note is that I've found that sometimes Kotlin/Scala will produce better bytecode and performance than what I would have written naively by hand.
Just due to them emitting horror-inducing code/optimizations that is great for performance but never meant for human eyes.
Yes, the languages that are foreign to the platform and require additional tooling to be usable, or have to generate code to fake host semantics.
JVM and CLR aren't the same thing in regards to guest languages.
JVM was designed for Java, and everyone has to fake being Java when generating bytecode.
CLR was designed just like WebAssembly, to be language agnostic runtime, initially released with VB, C#, J#, C++ and a couple of .NET versions of Oberon, Eiffel, Lisp, Scheme, COBOL.
Guest languages than tend to pick their own abstraction, which work great on year zero, and then get problematic as the platform decides to go into another direction, or the guest language decides it wants to break free and target multiple hosts.
Kotlin is a great example, due to its marriage with Android, its Java compatibility is caped to Android Java subset, or one needs to make use of KMM.
Additionally Java developer cannot easily consume Kotlin APIs based on co-routines, and it remains to be seen how they will integrate them with Loom.
Or the reboot they were forced to do in Kotlin/Native because it wasn't originally designed to be compatible with JVM semantics.
- There is Jetpack Compose currently, for Desktop, Web, and Android
- And Kotlin Native putting a large portion of resources into Skia bindings (JetBrains calls the lib "Skiko" https://github.com/JetBrains/skiko)
It's very clear (and there are some employees which have confirmed this IIRC) that they are working on "Jetpack Compose Everywhere" that runs on iOS as well, from a single codebase. Skiko Kotlin Native lets you use Skia to render on the web as well, if you compile to WASM target.
There's the big Kotlin event going on right now, where they just announced the new WASM backend and changes in their compiler + IR commonizing/restructuring ("K2").
The net result is that you wind up with a single language that you can use to write your backend API, your UI code (Jetpack Compose app deployed across Web/Android/iOS/Mac/Win/Linux, or transpile to JS/TS if you just want a web app, etc) and with Kotlin Native even your native, low-level code to integrate with existing C/C++ etc ecosystem.
KN already does automatic bindgen for C and Swift headers, they have direct C++ interop (like Swift does) on their future roadmap too:
All of this is mostly possible already -- I can do the same thing using IE Java, GraalVM, and a transpiler like Google's j2cl or bck2brwser (which is what Gluon uses for JavaFX on the web). Including the "native" part.
IE, here's a contribution I made to get GraalVM producing native binaries using Skia from the JVM + JNI Jetbrains Skia library (and even invoking my Java app methods as a .dll from C++)
Or one just uses JVM implementations instead, and yes they exist for all Kotlin target flavours, including iOS.
JetBrains wants to go big with Kotlin, and be a language vendor, lets see how they manage outside Android, where they aren't the godfather chosen language.
I've only used Kotlin for serverside development (Redhat's Quarkus framework) and experimentally Kotlin Native, though it definitely still has the reputation as "That Android language" for sure
Clojure explicitly embraces the host, and it is also one of the first thing people criticizes haha.
Language built for platform vs language ported-to platform
- Many new languages still take 'Language as platform' approach
- When ported, have platform-on-platform issues
- Memory management, type-system, threading issues
- Library duplication
- If original language based on C, some extension libraries written in C don’t come over
There's a lot of time where the core team says, Java already does this well, just use the one from Java.
Comments
That is one of the reasons I dislike guest languages, the communities tend to have a culture of rebuilding the underlying stack, as if not appreciating that it is what allows their favourite language to exist in first place.
What is a "guest language", haven't heard this term used outside of GraalVM before?
From context, it's a language that uses the platform of a host?
IE, JVM languages like Kotlin/Scala/Clojure when Java was the initially intended one? Or CLR languages like VB/F# which are second-class in comparison to C#?
If it is this, the one interesting thing I have to note is that I've found that sometimes Kotlin/Scala will produce better bytecode and performance than what I would have written naively by hand.
Just due to them emitting horror-inducing code/optimizations that is great for performance but never meant for human eyes.
Yes, the languages that are foreign to the platform and require additional tooling to be usable, or have to generate code to fake host semantics.
JVM and CLR aren't the same thing in regards to guest languages.
JVM was designed for Java, and everyone has to fake being Java when generating bytecode.
CLR was designed just like WebAssembly, to be language agnostic runtime, initially released with VB, C#, J#, C++ and a couple of .NET versions of Oberon, Eiffel, Lisp, Scheme, COBOL.
Guest languages than tend to pick their own abstraction, which work great on year zero, and then get problematic as the platform decides to go into another direction, or the guest language decides it wants to break free and target multiple hosts.
Kotlin is a great example, due to its marriage with Android, its Java compatibility is caped to Android Java subset, or one needs to make use of KMM.
Additionally Java developer cannot easily consume Kotlin APIs based on co-routines, and it remains to be seen how they will integrate them with Loom.
Or the reboot they were forced to do in Kotlin/Native because it wasn't originally designed to be compatible with JVM semantics.
Ah, I see what you're saying now.
sighYeah. BUT! I am very bullish on Kotlin. Think it's probably the most exciting language evolving right now.
I went on a few-tweet minirant here about why:
https://twitter.com/GavinRayDev/status/1443279425311805440
But the tl;dr is that:
It's very clear (and there are some employees which have confirmed this IIRC) that they are working on "Jetpack Compose Everywhere" that runs on iOS as well, from a single codebase. Skiko Kotlin Native lets you use Skia to render on the web as well, if you compile to WASM target.There's the big Kotlin event going on right now, where they just announced the new WASM backend and changes in their compiler + IR commonizing/restructuring ("K2").
- https://blog.jetbrains.com/kotlin/2021/10/the-road-to-the-k2...
- https://www.youtube.com/watch?v=-pqz9sKXatw
The net result is that you wind up with a single language that you can use to write your backend API, your UI code (Jetpack Compose app deployed across Web/Android/iOS/Mac/Win/Linux, or transpile to JS/TS if you just want a web app, etc) and with Kotlin Native even your native, low-level code to integrate with existing C/C++ etc ecosystem.
KN already does automatic bindgen for C and Swift headers, they have direct C++ interop (like Swift does) on their future roadmap too:
(Ctrl+F "interoperability")
https://kotlinlang.org/docs/roadmap.html#roadmap-details
All of this is mostly possible already -- I can do the same thing using IE Java, GraalVM, and a transpiler like Google's j2cl or bck2brwser (which is what Gluon uses for JavaFX on the web). Including the "native" part.
IE, here's a contribution I made to get GraalVM producing native binaries using Skia from the JVM + JNI Jetbrains Skia library (and even invoking my Java app methods as a .dll from C++)
https://github.com/HumbleUI/JWM/issues/158
But Kotlin is pushing the hardest to make this whole platform/stack from native <-> desktop <-> mobile <-> browser a seamless, unified experience.
And you can feel it, when you try to do the "whole stack, every platform, one language" thing.
Sorry for the rant and wall of text!
Or one just uses JVM implementations instead, and yes they exist for all Kotlin target flavours, including iOS.
JetBrains wants to go big with Kotlin, and be a language vendor, lets see how they manage outside Android, where they aren't the godfather chosen language.
I've only used Kotlin for serverside development (Redhat's Quarkus framework) and experimentally Kotlin Native, though it definitely still has the reputation as "That Android language" for sure
Clojure explicitly embraces the host, and it is also one of the first thing people criticizes haha.
There's a lot of time where the core team says, Java already does this well, just use the one from Java.