
Scala Native - virtualwhys
https://github.com/scala-native/scala-native
======
openasocket
Is this a "true" Scala? As in, if I write a Scala program that only uses the
scala stdlib, will it run on both the JVM and Scala native with no
modifications to the source? Or, is it more like "a Scala" in the same way you
would say "a Lisp"? I think a lot of the design decisions for Scala were made
so that Scala would work on the JVM and easily inter-op with Java. It might
make more sense to modify the language slightly to better suit the native
environment. I'm seeing some hints to that on the page with the "@struct" and
"@extern" decorators.

~~~
brianwawok
Clearly they added a bunch of new stuff that the JVM can't understand.

So it is either "Scala like LISP"

or

It is a superset of the Scala language. Meaning all existing stuff will work
with it, but if you use new secret keywords it will work "better".

Which seems not quite ideal, because that means most Scala libraries will not
be "tuned", and you will need all new libraries.. just like ScalaJS made you
need entirely new Scala libraries that did not use reflection.

Worried the Scala ecosystem is turning into a nightmare ;)

~~~
edem
The language is already a nightmare compared to a nearly syntaxless lisp so
I'm not surprised that the ecosystem follows suit.

~~~
acjohnson55
It's funny to me to see "syntaxless" used as a good thing :)

For me, syntax--good syntax, anyway--makes code far more readable.

~~~
cle
Maybe. Syntax imposes structural rules on your code. If your domain doesn't
fit the syntax, then you'll end up with far _less_ readable code. The draw
towards "syntaxless" lisp-y languages is that you can build the syntax to fit
your domain, rather than vice versa. The result is a DSL that naturally models
the domain, rather than an unintuitive mess of data transformations to force
your domain model to fit the structure imposed by the syntax and type
constraints.

~~~
pjmlp
This thing that each Lisp developer writes its own DSL library is one of the
reasons why the enterprise isn't so found of Lisp.

It is always a steep curve to dive into other developers code.

~~~
hukola
Wouldn't LISP become more popular if students started with LISP at
school/university rather than C/C++, Java or Python? How can a young developer
compare or choose if he/she had never been exposed to LISP?

~~~
pjmlp
It would help, but it isn't sufficient.

I had a very good CS degree in the mid-90's.

We got to use Pascal, C, C++, Prolog, Caml Light, Smalltalk, Oberon(-2),
Component Pascal, Lisp, SQL, PL/SQL, x86 ASM, MIPS ASM, Java, across the 5
years it used to take (nowadays thanks to Bologna is no longer the case).

It doesn't mean we got to use many of those languages afterwards.

But Lisp is a special case, if Lisp Workstations hadn't failed in the market
or if Sun and others hadn't picked UNIX as their Workstation OS, maybe it
would be different IT world, in spite of all DSLs I was referring to.

------
densh
Hi all, I'm the author of the project and would gladly answer any questions.

~~~
dtech
Do you see any possibilities to undo/mitigate JVM-specific design decision
which handicap the language? For example could you not erase generics or would
that cause too much problems incompatibilities?

~~~
whateveracct
Idiomatic Scala doesn't care at all about erased generics. With implicits and
macros and libraries built upon them like shapeless, you can do everything
you'd want to do with reified generics and more __and __it 'll be done and
statically checked at compile time instead of dynamically at run time.

~~~
dtech
I know there are ways like typetags to work around it, but on the JVM this is
never going to run without extra work:

    
    
        def erased[T](xs: List[T]) : String = {
          xs match {
            case ns : List[Int] =>"Natural numbers"
            case fs : List[Double] => "Floating point numbers"
            case _ : List[T] => "Something else"
          }
        }
        System.out.println(erased(List(1,2,3)))
        System.out.println(erased(List(1.0,2.0,3.0)))
    

Which is purely because of a JVM runtime limitation. Will native scala behave
identically to JVM scala in this case or will you be able to improve?

~~~
bad_user
The part that you're missing is that code like this in Scala is totally
unnecessary and it never happens:

    
    
        case ns : List[Int] =>
    

Worst case scenario, you can always do the following and it would be more
idiomatic, no type erasure standing in the way:

    
    
        val listInt = listAny.collect { case x:Int => x }
        val listDouble = listAny.collect { case x:Double => x }
    

But even that is totally unnecessary. You know why? Because your function does
not make sense. What could you possibly do with a function that takes a
List[T] and returns a String?

The only way this would make sense would be if you are talking about a
List[Any] deserialized from somewhere (like some shitty JSON library). But
then in Scala we don't really work with Any, that should never happen and if
you see libraries that use Any in their API, drop them like they are hot ;-)

> _Which is purely because of a JVM runtime limitation_

No it's not. Talk to compiler authors. This is actually a _freedom_ , because
by introducing reified generics in the runtime, then language designers either
have to deal with inefficiencies due to boxing because of extra conversions,
or to limit their type system, so for example you can say goodbye to higher-
kinded types. A runtime that has reified generics is not a multi-language
runtime. In fact many languages are doing type erasure. Haskell is doing type
erasure. And why shouldn't it, I mean, type casting and isInstanceOf checks
make no sense in Haskell.

------
dsabanin
Really excited about this. This is another reason why Scala is an extremely
valuable tool these days. With Scala JVM, Scala.js with React Native and now
with Scala Native (LLVM), there'll be literally nothing you can't do well with
it.

~~~
estefan
Does Scala.js with React Native work well? I avoided it because I didn't want
to complicate my stack or have to jump through hoops when reading the react
docs. If it all works well I might make the jump to scala front & back...

~~~
sjrd
Reportedly, it works really well. Have a look at
[https://github.com/chandu0101/sri](https://github.com/chandu0101/sri)

------
spriggan3
Just saw this on twitter. Scala, you have my attention. There were a lot of
talks about "the tools of yesterday" and "the tools of the future" lately.
Scala getting closer to the metal, without the JVM is a significant step
toward "the tools of the future".

~~~
pfarnsworth
I've heard a lot of the early adopters of Scala are moving away, including
LinkedIn, Twitter, etc.

~~~
airless_bar
No, not really.

Some people from losing ecosystems like to spin it that way¹, but the truth is
people are happy, adoption is great, and companies see that pain-points get
addressed.

Of course there are companies which drop Scala, but often like in LinkedIn's
case it's not caused by a dissatisfaction with Scala, but new leaders making
different decisions like "we are using 10 different languages, we should
consolidate on X and Y!".

The last unhappy company which is commonly mentioned is this social-network
company Yammer. That was half a decade ago, and most of the issues mentioned
have been addressed in the mean time. (Yammer has been bought by Microsoft, so
it also made some sense to use a language that makes getting bought out
easier.)

¹ I remember there was some very very bitter Groovy evangelist a while ago.

~~~
pfarnsworth
I know for a fact LinkedIn dropped Scala because of dissatisfaction over
Scala. Things like maintainability, the fact it was just a single company
developing Scala, etc that caused them to switch away.

Kafka is deprecating their Scala clients because of maintainability issues as
well. Scala keeps making breaking changes on dot releases, making it
impossible to maintain long term.

~~~
kod
That's funny, when I talked to Neha (ex-Linkedin, cofounder of Confluent) she
explicitly denied this meme about moving away from Scala.

The new Kafka client library is in Java just to reduce the number of
dependencies, the server is still written in Scala. Strangely, using Java
hasn't stopped Confluent from making breaking changes on dot release of the
client... which really puts the lie to your explanation.

~~~
pfarnsworth
I specifically said the Scala clients are being deprecated. Go ask Neha to
confirm this.

~~~
kod
No, you specifically said they're being deprecated because of maintainability
issues inherent to scala, which is not true.

~~~
pfarnsworth
Nope. They were getting sick of having to maintain different versions of the
Scala clients because of breaking changes, as per a Kafka committer.

~~~
kod
Even if some random kafka committer that you can't source believes that, the
reasoning doesn't add up:

SBT makes it fairly straightforward to cross publish for different dot
releases of Scala, and libraries in the Scala ecosystem do it all the time.

Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10
released in 2012.

By contrast, the JAVA client that the Kafka project published in November is
already undergoing breaking changes for the current release candidate. It's
pretty clear that avoiding breaking changes is not an overriding concern for
them, and even if it is, it's equally clear that Scala was not the inherent
problem.

------
abc_lisper
Hi, Some questions

\- Can this reuse existing Scala code?

\- How does it compare against Rust/GO/Swift? Why use this over them?

\- How about libraries?

~~~
edko
A difference is that Scala can run on the JVM, the browser (and other JS
ecosystems) via ScalaJS, and now native. It doesn't get more universal than
that!

~~~
pjmlp
Native is all that it takes. Bytecodes are great for optimization passes and
interactive development sessions.

Java should have gone the native route for deployment, instead of having a few
architects at Sun being religious against AOT compilation.

~~~
edko
The other two are important too: the JVM lets you leverage lots of existing
libraries. The browser lets you reach more users.

~~~
pjmlp
Yes, but many of the use cases those libraries cover are also covered by other
libraries.

The browser, well personally I am not a big fan for anything besides
interactive hypertext documents. Even though I worked several years as web
developer, I tend to favor native + network protocols instead.

Many researchers jumped into the JVM because it provided a fertile ground for
language research, without having to build their own.

Apparently LLVM brought a change to that and now everyone is using it instead
of the JVM for language research, with the benefit of always having JIT and
AOT toolchains, with GCC trying to follow up on that.

What I dislike in the JVM was the religion against AOT compilation (only third
party commercial JVMs offer it) and missing out on value types, even though
Eiffel, Oberon and Modula-3 where all having them.

Personally I think all language toolchains should offer JIT/AOT, with the
developers using the best one for each deployment use case. Although for
dynamic languages, AOT is probably not a good use case.

------
gnufied
So, is this "released" yet? There are no downloadable installers or even
instructions to compile.

~~~
Scarbutt
Looks like its based on dotty so Java 8 is a requirement.

~~~
densh
It's currently based on Scala 2.11 with 2.12 and Dotty support coming in the
future.

------
grandinj
Given that Apache harmony is no longer being developed, you might want to
coordinate with the Avian people, since they also reuse harmony.

------
CheKhovHemingw8
Another thread covers in hands-on way Getting Started:
[https://news.ycombinator.com/item?id=11699897](https://news.ycombinator.com/item?id=11699897)

------
smegel
What about GC?

~~~
densh
In a first release we're going to use Boehm GC. That's just a stepping stone,
not a long-term strategy. Stay tuned for news on this front.

------
partycoder
In a way, simple Scala code resembles Swift, as commented by this person:
[https://leverich.github.io/swiftislikescala/](https://leverich.github.io/swiftislikescala/)

Now the type system of course is entirely different.

~~~
kbenson

        val label = "The width is "
        val width = 94
        val widthLabel = label + width
    

I really wish more languages would distinguish concatenation from addition,
_especially_ when they do type coercion. There's a very specific reason Perl
opted for '.' to concatenate strings instead of +, which is that it
disambiguates the following:

    
    
        val first = "2"
        val second = 3
        val together1 = first + second
        val together2 = second + first
    

Not to mention, addition is commutative and concatenation is not (1+2 == 2+1,
but "one" \+ "two" != "two" \+ "one")

Hopefully Scala at least has some very well defined and _easy_ rules for
exactly how string concatenation works, but I think it's an uphill battle to
argue that '+' is a good concatenation operator.

~~~
int_19h
'+' works great as a concatenation operator, so long as you don't ever try to
implicitly convert the values. Case in point - Python:

    
    
      >>> 1+2
      3
      >>> "1"+"2"
      '12'
      >>> "1"+2
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      TypeError: Can't convert 'int' object to str implicitly

~~~
kbenson
Those are literals, not variables. My whole argument is about the ambiguity
introduced when you are implicitly coercing variables. But yes, if the
language does not coerce between string and numeric types, it's a non-issue.
I'm specifically talking about supporting coercion but continuing to use '+'
for concatenation of strings (and ==/!= for equivalence testing of strings as
well).

------
OhHeyItsE
Otherwise known as "Haskell"?

~~~
saosebastiao
Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost.
Any similarity to Haskell is incidental to Haskell/ML's shared background in
strongly typed functional programming.

~~~
OhHeyItsE
Incidental? It's pretty well known that Scala was heavily influenced by
Haskell. In particular, do notation (for comprehensions), pattern matching,
lots of standard lib classes (ex Maybe (Option)), many of the methods in the
collections library (map, fold, take, etc)

Anyway, I wasn't trying to disparage either of them (or this project). Just
poking fun at the seemingly common "I want to use Haskell but I'm forced to
deploy on the JVM" use case for Scala.

~~~
saosebastiao
> It's pretty well known that Scala was heavily influenced by Haskell.

Except that Martin Odersky himself has explicitly said that the primary
influences were SML/OCaml and Java.

> In particular, do notation (for comprehensions),

I'll give you that one

> pattern matching

Which pre-date Haskell by nearly 2 decades in ML

> lots of standard lib classes (ex Maybe (Option)),

Also pre-date Haskell by nearly 2 decades, in addition to be named exactly the
same as ML.

> many of the methods in the collections library (map, fold, take, etc)

Which pre-date Haskell by almost 4 decades with origins in LISP.

> Just poking fun at the seemingly common "I want to use Haskell but I'm
> forced to deploy on the JVM" use case for Scala.

Which is where the Scalaz folks come in. They want to piggy back off of
something successful, as opposed to Frege, which is closer to what they
actually want (avoiding success at all costs?). Who knows, maybe they actually
like the strict-evaluation by default of Scala/ML, which is quite pragmatic,
but definitely more in line with ML than Haskell.

~~~
runT1ME
Given the fact that OCaml seems to be adding type class support and has
support for monadic comprehension (do/for), it seems like these ideas are
getting adopted in multiple places.

As a Scalaz committer and as a developer working at one of the largest scala
shops (that makes heavy use of Scalaz), we don't try to write Haskell on the
JVM. We do try to write pure, functional code as much as we can, and so what
we end up with falls somewhere in the middle between an OCaml and Haskell.

~~~
saosebastiao
> OCaml seems to be adding type class support

Funnily enough, Scala's implicit-based type classes were the inspiration for
the coming modular implicits type classes in OCaml (as opposed to the Haskell
approach). It wouldn't be the first time that two languages have mutually
inspired each other (The Rust and Swift teams have both acknowledged certain
design decisions inspired by the counterpart).

------
jiang101
Wow, they're even planning to provide a native version of the runtime library?
That will be more than nice.

------
airless_bar
Not the author:

> \- Can this reuse existing Scala code?

I think that's the plan. Would be a pretty pointless exercise without that,
right? :-)

> \- How does it compare against Rust/GO/Swift? Why use this over them?

Rust: Scala and Rust have different niches. Rust is more focused on low
runtime overhead, while Scala is more focused on low development overhead.
This means Rust can be potentially faster to run, but Scala is faster to
develop.

Go: Go is utter shit that only survives due to the devs name-dropping "Google"
every 5 minutes.

Swift: Scala is more mature, simpler, better designed. Not a knock against
Swift, but there is a difference between a language where changes have been
tried experimentally for years before either adopting or removing them, and
Swift where things get added at a frightening rate.

> \- How about libraries?

Libraries without Java dependencies should work, libraries with Java
dependencies depend on whether their Java dependency is provided by Scala-
Native (just like on Scala.js).

~~~
lauriswtf
A small side note: Scala has several great features, but "low development
overhead" just isn't one of them. Also why so harsh on Go?

~~~
kod
If by low development overhead you mean amount of crap you need to type in
order to get things done, Scala absolutely does have low development overhead.

As for Go, I'd say that's the most honest description of the language I've
seen in a while.

~~~
placeybordeaux
If your limiting factor is how fast you can type you are either an amazing
person that should be studied or you need to take a typing class.

~~~
lmm
My limiting factor is usually how fast I can comprehend other people's code,
and the extraneous crap some languages require can often be the biggest
contributor to that.

