Secondly, there are several ways how Java source code becomes machine code, depending on which JVM and JDK is being used, not taking into account the ART cousin.
Then you have Metals for VSCode InteliJ plugins, while the Eclipse plugin was dropped.
InteliJ plugin is much further than Metals, however there is the conflict of interests with pushing Kotlin instead.
Meanwhile most Scala shops have pivoted to also give feature parity on modern Java, and Kotlin, thus reducing the interest in using Scala in first place.
However as mentioned, they are doing cool stuff with capabilities at EPFL for Scala 3.
All three major programming environments at Xerox PARC, shared similar concepts.
Interlisp-D, Smalltalk, Mesa (XDE) which evolved into Cedar.
If you read Xerox papers about all of them, there are several quotes on how relevant it was to share the same programming experience across environments.
Which is why, given their linage, JVM and CLR are the closest big mindshare ecosystems that somehow still have traces of those features when using their IDEs and runtimes, even without being a proper Smalltalk or Lisp.
The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.
> A common refrain is that Emacs is an operating system (OS). This isn’t true, but what invites comparison to an OS is its ability to orchestrate applications and utilities above the OS kernel level.
Only because Lisp Machines, or variations thereof didn't took off in the mainstream.