Scala Native v0.1

I would love for there to be a similarly thorough project with Clojure. It really bothers me there's no good native compiler. Apart from anything else, it means that Clojure lives and dies by the languages it compiles to, and while Java is used everywhere still, it probably isn't the thing the kids are learning these days. Besides, without going into any further rational arguments for why using the JVM (or another VM) isn't always great, something about it feels a bit icky to me. On an aesthetic level.

This will be huge for getting Scala running on AWS Lambda. The cold-start times for JVM apps is just ridiculous and makes Lambda/API gateway essentially unusable for anything written on the JVM.

It seems to me like Scala's biggest benefit and biggest downside are two sides of the same coin: easy interop with the JVM and Java code. Scala Native just seems like you're paying all the price of that for none of the benefit.

That&#x27;s a great news ! We are exclusively using scala at work for back end and I wonder if it could be interesting to switch new projects to scala native.<p>Did you test scala native against well known and massive open source scala project ? Did the performance improved or regress ? Did you wrote a brand new scala compiler for native code ?

Scala is a language I desperately wanted to like - high level, statically typed pure OO language. But in practice I found it almost unusable. The type signatures were unreadable and I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler. And the tools themselves were huge memory hogs - sbt was a particularly bad offender (though otherwise quite pleasant).<p>I also did not get on well with the community, which seemed to have a lot of people with the attitude - &quot;they won&#x27;t let me use haskell at work so I&#x27;ll make do with this shit&quot;. They didn&#x27;t seem to understand or be interested in OO at all, and were very fanatical about driving application logic with types, purity, and the like.<p>Regardless, a native variant would be something well worth investigating if it ever reaches &quot;production ready&quot;.

As a Scala guy on a Scala team, I&#x27;d think this would be most immediately useful on smaller fill-the-gaps sub-projects where we have to integrate with native code.

This is extremely exciting. I can&#x27;t wait to try this out.<p>On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

Will macros work with Scala Native, as they do with ScalaJs? (I believe that compile-time metaprogramming is the way forward, especially if the target doesn&#x27;t support reflection or dynamic code loading).

This is <i>amazing</i>. Scala is one of my favorite languages to work with, and getting it native-code support will finally help make it fast enough to justify using it <i>everywhere</i>.

Somewhat relevant: <a href="https:&#x2F;&#x2F;blog.plan99.net&#x2F;kotlin-native-310ffac94af2#.ijzik0jxx" rel="nofollow">https:&#x2F;&#x2F;blog.plan99.net&#x2F;kotlin-native-310ffac94af2#.ijzik0jx...</a><p>Title says Kotlin, but it is about JVM languages going native, in general. Or should they?

I can&#x27;t get hello_world to work, something about a unresolved dependency: org.scala-native#sbt-Scalia-native;0.1.0: not found<p>I&#x27;m not a regular Scala user.

Great! Any benchmarks on whether the Scala compiler runs faster when compiled to native?

Nice work, I hope this will eventually be a serious alternative to the JVM route.<p>Quick question: does this compile down to DOT before going to LLVM? Or has DOT not yet arrived in Scala Native?

Question: what kind of frameworks can be practically migrated to Scala Native?

Does anyone have any example binaries compiled with this? What are the sizes that you could expect?<p>They say one of their targets is using this for command-line tools (I&#x27;m guessing for startup speed and needing to be small in memory footprint) but it&#x27;s not of much value if an &quot;echo&quot; or &quot;grep&quot; implementation takes up 15 to 30MB on the drive.

I&#x27;ve created once custom barebone JavaVM with binary size of around 100k. It was made as an executable jsmile.exe that was capable to read bytecodes cat&#x27;ed to the executable itself : <a href="http:&#x2F;&#x2F;www.terrainformatica.com&#x2F;org&#x2F;j-smile&#x2F;index.htm" rel="nofollow">http:&#x2F;&#x2F;www.terrainformatica.com&#x2F;org&#x2F;j-smile&#x2F;index.htm</a><p>The goal was to create JVM suitable for standalone GUI applications. Project was abandoned when Sun&#x2F;MS Java wars started in favor of the Sciter (<a href="https:&#x2F;&#x2F;sciter.com" rel="nofollow">https:&#x2F;&#x2F;sciter.com</a>).<p>As of NativeScala ... I think that approach (binary with nano JVM + attached class files) may work better and with less effort. Scala needs JVM infrastructure, GC, etc. as far as I understand.

How do the compilation times compare to targeting the JVM?

so dream comes true!<p>P.S. I think this is related to rust, in a sense before Rust there was no serious competitor to C&#x2F;C++, but after seeing what Rust doing to C&#x2F;C++ I think there will be more native language to compete with in low level area.

At first glance of this article&#x27;s title, I thought it would be a terrible idea to use Scala to write native mobile applications. Imagine using Scala.JS to write a NativeScript&#x2F;React Native app. <i>shutters</i>

It seems like that would open up a nice way of using Scala on iOS also.

&gt; This opens the door for Scala to be used in environments where full-blown virtual machine is usually an overkill<p>Not sure if I get this, don&#x27;t Java VMs support this use case (J2ME) ?

Important bit: &quot;The project has reached a point of feature completeness in terms of the coverage of the Scala language. We support the whole language including the more advanced features such as method dispatch via structural types and even macros.&quot;<p>It must be frustrating to work on a project like this, see areas where the language can be improved, but only be able to do the work to make it purely compatible. Hopefully some good comes out in the form of some good SIPs.

The generated binary for simple Hello World is 3.45 MB which is quite a lot for printing one line of text but it can be compressed to 326K using UPX.

This is certainly an impressive piece of work. However, i think it&#x27;s worth paying attention to the limitations, and the use cases they imply; overall, this looks less like &quot;compile your existing Scala app to native code!&quot; and more like &quot;use Scala to interface with existing native libraries!&quot;.<p>On the other hand, it&#x27;s also worth bearing in mind that this is version 0.1.0; over time, some of these limitations will lift. What i don&#x27;t know is whether Scala Native will develop into a complete version of Scala which compiles to native code, or evolve into a variant of Scala more tightly adapted to a niche of talking to native libraries.<p>Anyway ...<p>(1) No threading [1]:<p><i>Scala Native doesn’t yet provide libraries for parallel multi-threaded programming and assumes single-threaded execution by default. It’s possible to use C libraries to get access to multi-threading and synchronization primitives but this is not officially supported at the moment.</i><p>So forget about using Akka for now.<p>(2) NullPointerExceptions are replaced with segfaults (hopefully) [1]:<p><i>A number of error conditions which are well-defined on JVM are undefined behavior: Dereferencing null. Division by zero. Stack overflows. Those typically crash application with a segfault on the supported architectures.</i><p>That&#x27;s not so bad; where Java apps might let nulls flow around and rely on catching NullPointerExceptions to recover from them, Scala apps are much more likely to use Optional consistently.<p>(3) If you do want to talk to a native library, and you need to allocate memory to do it, you&#x27;re on your own [2]:<p><i>Unlike standard Scala objects that are managed automatically by the underlying runtime system, one has to manage native pointers manually.</i><p><i>Scala Native provides a built-in way to perform stack allocations of unmanaged memory using native.stackalloc function: [...] When using stack allocated memory one has to be careful not to capture this memory beyond the lifetime of the method. Dereferencing stack allocated memory after the method’s execution has completed is undefined behaviour.</i><p><i>Scala Native’s library contains a bindings for a subset of the standard libc functionality. This includes the trio of malloc, realloc and free functions</i><p>Java&#x27;s traditional JNI is a verbose, slow, pain in the stdout, but it was designed pretty carefully to avoid problems like this.<p>(a) Intermission! Check out how they do type-level numbers [1]:<p><i>Natural numbers are types that are composed of base naturals Nat._0, ... Nat._9 and an additional Nat.Digit constructor.</i><p>That&#x27;s a new one on me!<p>(4) Incomplete JDK libraries [3]:<p><i>Scala Native supports a subset of the JDK core libraries reimplemented in Scala. Here is the list of currently available classes: [...] This is an ongoing effort, some of the classes listed here might be partially implemented.</i><p>The list has most of the fundamental stuff - a good chunk of java.io and NIO, the collections, java.lang, atomics. But no java.text, java.net, concurrency, regexp, date and time, JDBC, reflection, XML, etc.<p>They don&#x27;t mention how much of the Scala libraries they support. I would imagine that they can build anything that&#x27;s in pure Scala and depends only on JDK classes in that list, so you&#x27;ll get the core language stuff and the collections. Not sure.<p>[1] <a href="http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;user&#x2F;lang.html" rel="nofollow">http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;user&#x2F;lang.html</a><p>[2] <a href="http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;user&#x2F;interop.html" rel="nofollow">http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;user&#x2F;interop.html</a><p>[3] <a href="http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;lib&#x2F;javalib.html" rel="nofollow">http:&#x2F;&#x2F;www.scala-native.org&#x2F;en&#x2F;latest&#x2F;lib&#x2F;javalib.html</a>

I wonder if Akka will be a part of scala native? It&#x27;s sort of considered stdlib? When our team spiked on Akka, we liked it and got our near-reality proof of concept to work. It&#x27;d be awesome to have such a high level library like Akka compile to a binary.

Nice job, thanks! Seems that right now you had implemented some wrappers for libc and some java classes ported to scala. What plans do you have to further evolve API? Will you focus on reimplementing java.* or create your own set of classes?

Is Scala Native GCed?

Does this mean the future of Scala is off the JVM? I ask because the post calls the JVM impl. a &quot;reference implementation&quot;.

Does this provide a garbage collector?

Any Windows pre-built binary to try?<p>I imagine building this stuff on Windows will be challenging :&#x2F;

Will this mean that we can get rid of type erasure when running native code?

Will language support destructors for manual memory management ?

good idea!

Most things called native are not.

Unfortunately, this requires an existing Scala compiler to build, so it won&#x27;t be useful as a bootstrap compiler for Scala on the JVM. Does anyone here know of an alternative implementation of Scala that could be used to build the libraries and tools of the reference implementation from source?<p>It is a problem that many compilers cannot be bootstrapped from source without a trusted binary of a previous release.