
Scala Native 0.3.7 - joshlemer
https://github.com/scala-native/scala-native/releases/tag/v0.3.7
======
dtech
I really like (and work in) Scala, and Scala native is an interesting project.

However, its use cases seem to be encroached on all fronts.

If you want native, performance and don't need the JVM ecosystem, Rust and go
both take very different but good approaches to that problem. I would have a
hard time recommending Scala Native over Rust.

If you want browsers, Javascript is rapidly evolving and becoming a better
lanuage. Typescript adds an excellent type system given the constraints its
working with. Webassembly opens the door to use your own favorite. I would
have a hard time recommending Scala.js over Typescript.

If you want JVM, Java is adopting traditional Scala killer features at a
glacial pace, lambda's in 8, pattern matching in 11+ [1], Data/Case classes in
? [2], but adopting them nonetheless. Kotlin has succesfully performed a
Blitzkrieg maneuver on Scala's "better Java" territory and has full support
from Google in Android. It's also much more approachable for Java devs. I have
a hard time convincing JVM devs that Scala is a good choise over Kotlin. At
the place I work in all new projects are Kotlin, and Scala is used for the
projects that were started in it.

Python and R are mainstays in the data science world, with Spark serving as a
sort of Scala bastion.

I like scala, and follow its developments and 3.0 (Dotty) version somewhat,
but I am slowly seeing it dwindling into irrelevance.

[1] [http://openjdk.java.net/jeps/305](http://openjdk.java.net/jeps/305) [2]
[http://cr.openjdk.java.net/~briangoetz/amber/datum.html](http://cr.openjdk.java.net/~briangoetz/amber/datum.html)

~~~
tanin
There's one case missing: Build a command-line tool with concise and
maintainable code; Performance is not important.

Scala Native would win over Rust and Go, which are too low-level. Scala Native
would win over python/ruby because of the ease of deployment (e.g. compile to
target CPU) and static typing.

However, Crystal probably wins over Scala Native...

~~~
walkingolof
Go is probably a winner for the time being for CLIs, just the fact that I can
cross compile for 3 platforms with a very simple script makes it very
attractive.

~~~
koolba
Specifically it can cross compile to a _static_ executable. It’s quite
pleasant to just copy a compiled Go program and have it just work.

------
tunesmith
Had my first experience playing with Scala Native a couple of weeks ago, for
hacking together a simple vote-counter
([https://github.com/tunesmith/condorcet-
counter](https://github.com/tunesmith/condorcet-counter)) and am enjoying it
just because I'm able to do all the scala goodness I want (test cases, types),
while also be able to run it quickly from the shell.

I couldn't figure out the IntelliJ tooling, though, that's still lagging. I
have to turn off the scala-native plugin to get the IDE to recognize the code,
and then turn it back on whenever I want to generate the executable.

------
lobster_johnson
Out of interest, how will Scala Native work with projects like Apache Spark,
which rely on shipping JARs around in order to run the same code on multiple
nodes? Would you build "native" JARs containing object code?

~~~
logicfiction
I don't think Scala Native would be a good fit with Apache Spark. Starting
with their work in 2.0, the Spark framework already started doing things like
working with sun.misc.Unsafe for direct memory control over certain
operations. In general they put a lot of effort into getting as close to metal
and hyper-optimizing the framework itself. Given that, trying to do the same
yourself on top of that framework seems counter-intuitive in my opinion.

~~~
lobster_johnson
Surely a goal with Scala Native is performance and things like "direct memory
control" (why else move away from the JVM?), which would very much dovetail
with the work being put into Spark?

~~~
lmm
The JVM has had native-like throughput for long-running batch processing jobs
for years - of course you can always tune further, but it already fits nicely
with what Spark is used for. Scala Native makes more sense for things like
command-line utilities that need to start up quickly, or in the future maybe
real-time systems that need to avoid GC.

