This is AWESOME to see/hear!
Hello,
Indeed, I confirm that the Scala Center does not work on Scala Native currently. I’ve posted a slightly more detailed message about that here: The Typelevel stack and Scala Native - #8 by julienrf
2 Likes
I would say for most projects to become successful there needs to be some killer “app” or feature, for scala-native this is what comes to mind
- Potential for higher performance than JDK/GraalVM. This is result of the fact that both JDK and GraalVM use the JVM bytecode and the translation from Scala source to JVM bytecode loses information that can be used for higher performance. Techniques such as fusion which along with a way to track purity can provide higher performance, as well as knowing immutable datastructures (one of the reasons why OCaml’s GC is so fast is it can take advantage of this)
- More fine grained control of the GC. While the JVM is a world class GC it is a double edged sourced in a lot of cases particularly when it comes to controlling the GC in a fine grained manner (i.e. not globally with flags). scala-native has much nicer interopt with C (allowing you to bypass the GC entirely) and with the flexibility of the scala language can provide better abstractions for controlling the GC, i.e. think of Rust style regions represented as a Scala
trait
that you can mixin with datastructures where you want to control when GC happens. Issues like this (and others) is in my view one of the main reasons why Java has never taken off when it comes to games (or at least non trivial games) and along with a proper multithreading implementation I can even see game engines using Rust + Scala native (with scala-native for higher level stuff such as game logic) and Rust with the engine, both being compiled together with LLVM - CLI apps/IOT: As you mentioned startup time is not usually that much of a difference but it can still matter. With having native binaries you do have other options opened up, such as much easier packaging options (don’t need to package or worry about a JDK). While GraalVM can also solve this problem, scala-native’s footprint by default is smaller which also means it can work nicely with IOT style devices.
- GUI apps. While swing exists, the ergonomics and design of the GUI toolkit can be argued as questionable. For example, Intellij ended up having to fork OpenJDK (see Home · JetBrains/JetBrainsRuntime Wiki · GitHub) in order to add capabilities such as HiDPI as well fixing the performance issues (mainly latency) associated with the JDK. Ontop of this, Scala’s language design is in my opinion is one of the nicest languages to program GUI’s in. Its blend of OO and functional programming really gives you the best of both worlds to write GUI’s (while OO is definitely overused, one area where it still shines is UI toolkits). This along with modular features such as
trait
s makes Scala extremely powerful in modelling GUI’s. For these reasons scala-native is much more prepositioned to integrate better with native ui toolkits than JDK/Java/GraalVM.
2 Likes
In addition to this, GraalVM can be quite painful to set up (for instance, logging and cloud libraries have taken me more time than I wished to), and the resulting binaries are quite large. Scala Native produce smaller and more performant binaries, which is great for a whole range of apps: microservices, CLI, native GUI, …
5 Likes