Comment by nicoburns
2 days ago
The userspace being tied to the JVM is a massive pain. Certainly it's a lot harder to bind to than any other OS's system libraries.
2 days ago
The userspace being tied to the JVM is a massive pain. Certainly it's a lot harder to bind to than any other OS's system libraries.
How so?? JVM bytecode should be much easier to bind to, as the existence of JVM alternative runtimes for nearly every language shows.
Unless you're using a language that's specifically compile-to-jvm (e.g. Java, Kotlin or similar), almost nobody is using those JVM alternative runtimes. They're usually second-class runtimes that don't run the entire ecosystem of the target langauge. React Native runs JavaScript in a separate JS VM, Flutter is compiling Dart to native code with emdedded runtime, and Rust UI code also compiles to a native binary.
The "lingua franca" for language bindings is the C ABI which every other OS's platform libraries (Win32/Cocoa/GTK) support.
> The "lingua franca" for language bindings is the C ABI which every other OS's platform libraries (Win32/Cocoa/GTK) support.
Which is more like half of an API, it doesn't specify lifetimes so basically anything behind a pointer is unusable in itself. That's why we have "hacks" like gobjects and such, and why using most of the bindings is only possible if you have a decent binding library.