Will this mean that we can get rid of type erasure when running native code?
Scala Native v0.1
161–170 of 254 posts
Re: Scala Native v0.1
#162At first glance of this article'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/React Native app. shutters
> Imagine using Scala.JS to write a NativeScript/React Native app.
People do [1], and are very happy with it.
Re: Scala Native v0.1
#163This is certainly an impressive piece of work. However, i think it's worth paying attention to the limitations, and the use cases they imply; overall, this looks less like "compile your existing Scala app to native code!" and more like "use Scala to interface with existing native libraries!".
On the other hand, it's also worth bearing in mind that this is version 0.1.0; over time, some of these limitations will lift. What i don'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.
Anyway ...
(1) No threading [1]:
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.
So forget about using Akka for now.
(2) NullPointerExceptions are replaced with segfaults (hopefully) [1]:
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.
That'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.
(3) If you do want to talk to a native library, and you need to allocate memory to do it, you're on your own [2]:
Unlike standard Scala objects that are managed automatically by the underlying runtime system, one has to manage native pointers manually.
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.
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
Java's traditional JNI is a verbose, slow, pain in the stdout, but it was designed pretty carefully to avoid problems like this.
(a) Intermission! Check out how they do type-level numbers [1]:
Natural numbers are types that are composed of base naturals Nat._0, ... Nat._9 and an additional Nat.Digit constructor.
That's a new one on me!
(4) Incomplete JDK libraries [3]:
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.
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.
They don't mention how much of the Scala libraries they support. I would imagine that they can build anything that's in pure Scala and depends only on JDK classes in that list, so you'll get the core language stuff and the collections. Not sure.
[1] http://www.scala-native.org/en/latest/user/lang.html
Re: Scala Native v0.1
#164Will this mean that we can get rid of type erasure when running native code?
Why is type erasure necessary anyway? Surely this can be worked around somehow. You could manually do what you do with array length in C - pass the information along manually. Why can't the compiler do this in a transparent manner for us? Is it speed?
Re: Scala Native v0.1
#165Earlier quoted context omitted.
If you include idiomatic Java programing as part of sloppy programming I also agree with that. https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
Many things pointed out in this article apply to just about every managed language runtime. Implement a TreeSet in any language and you'll see the same overhead from object headers, memory alignment, etc. Java has some oddities that cause it to waste extra memory, but off the top of my head the only I can think of is 16-bit character Strings. Java 9 is supposed to help with that by allowing Strings to internally stor…
Go uses quite a bit less memory than Java.
Re: Scala Native v0.1
#166Earlier quoted context omitted.
From that page, it looks like Scala-C interop is decent, but that's a far cry from C++/Rust interop. For C++ at least, you more or less need to write a pure-C wrapper API to call from Scala, since it doesn't handle C++ types.
You would need the same for Rust as well.
Rust's FFI is the same as C.
Re: Scala Native v0.1
#167Earlier quoted context omitted.
When you are writing that full-blown HTTP REST server with DB access you would probably be served better on the JVM. Scala native is just as garbage collected as Scala JVM and garbage collection is where the JVM shines brightly. In my eyes, the main value proposition of Scala native will be "you don't have to learn a new language if you need to write an echo or a grep", with "you don't need to learn a new language if…
A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot. Nice handle BTW. lol
Is this actually the case? I'd assume that Scala has the same dynamic nature as Java, and so AOT won't be able to convert dynamic dispatch to static as frequently.
Re: Scala Native v0.1
#168Earlier quoted context omitted.
Never touch a running system ;) Scala on JVM is much more tested than the new shiny thing. Also don't expect improved performance... many people think that the JVM is bloated and makes programs slower (this is mostly not true). The downsides of the JVM are more memory consumption/footprint (when you have e.g. small servers or micro instances) and the cold startup time of the JVM itself (which is not relevant on a ser…
Long time Java lover here. I agree with all your points, but in the context of Java at least (does Scala support this?) there is no simple static binary that can be built and released, which includes the JVM. I think 1.9 will have this option, but this is something I didn't realize I missed until I started work with Rust and Go. It makes deployment so much simpler.
Does it really need to be a binary? Build executable jars (use the maven shade plugin), run them with java -jar foo.jar, that's about as simple as it gets.
Re: Scala Native v0.1
#169Earlier quoted context omitted.
I disagree. Having a common language in many places has led to huge improvements over the board in the JS ecosystem, it's become the "C" of the modern era, and you can build a lot of stuff on the foundations that others have laid. I still hate JS though.
Which is anything but positive, as it also shares C's style of unsafety due to its semantics.
Which is ultimately irrelevant here. Consider, C is rock solid safe compared to machine/assembly.
(Though, I tend to share the annoyance of javascript...)
Re: Scala Native v0.1
#170Earlier quoted context omitted.
Long time Java lover here. I agree with all your points, but in the context of Java at least (does Scala support this?) there is no simple static binary that can be built and released, which includes the JVM. I think 1.9 will have this option, but this is something I didn't realize I missed until I started work with Rust and Go. It makes deployment so much simpler.
In the age of containers it's really not that much harder to build and deploy a JVM app. Edit: thanks for the downvotes but you could at least tell me what's so crazy about my statement.
To my mind the JVM is where containers make the least sense. If you build an executable jar you can run with "java -jar ..." then that seems just as simple as "docker run ..." and gets you the single-file deployment, and you can control memory allocation via flags if you need to. You don't get virtual networking but IME that doesn't add value in the first place.