
Scala Native - big_chungus
http://www.scala-native.org/
======
azinman2
I'm curious to know the target user. There's no JVM interop, so one of the
main reasons to use Scala -- an evolution of Java the language -- is out. Plus
with Kotlin even that reason is being outdated, especially as you lose all the
type conversions between Java arrays and Scala arrays, etc. Their C struct
example has a lot of awkward syntax, so it seems that it's a bit 'bolted on'
versus inherently designed for this use case. We have both Swift and Rust as
great higher-level languages that compile to native applications with C
interop, with more robust ecosystems and faster progress (Scala moves at
glacial paces in comparison)... both appealing for different use cases.

I used to be a Scala enthusiast before these alternatives existed. What place
does Scala now have in the world?

~~~
bad_user
For me Scala was never about using a Java++.

If you want Java++, the best Java++ is still Java with a bunch of libraries.
You don't need a new language for that.

Kotlin's succes is effectively because Google was late to port Java 8 to
Android. A fine language btw, but it will either become more like Scala, or it
will wither away eventually. My bet is in it becoming more like Scala, as
evidenced by arrow-kt.io

Scala has a blend of features that makes it the most expressive mainstream
functional programming language, most importantly ... implicits, by which you
can model typeclasses and higher kinded types.

And in Scala we've got an active community of FP libraries. Actual FP,
emphasizing referential transparency, with abstractions built for suspending
effects.

It's a little known fact but the kind of FP programming we do in Scala tends
to be more pure than what happens in OCaml, F#, Erlang, Clojure and others.

Also, we have a Scala to Javascript compiler, all the tooling works with it
and we've got an ecosystem of libraries cross-compiled to Javascript.

As for Scala Native, it has its place. The problem has been lack of manpower
to bring it to the maturity that Scala.js is at.

~~~
willtim
> It's a little known fact but the kind of FP programming we do in Scala tends
> to be more pure than what happens in OCaml, F#, Erlang, Clojure and others.

I have only dabbled in Scala, but IMHO it's more suited as an OCaml with
first-class modules. Why not use Haskell, if you don't need the JVM?

~~~
bad_user
Compared with OCaml, Scala can express type classes and has higher-kinded
types. Many abstractions that are easy to express in Scala are in fact hard to
express in OCaml.

For-comprehensions are worse than Haskell's do-notation or compared with F#'s
computation expressions, but the list ends there. In practice they work well
and at least Scala has monadic for-comprehensions. How many other languages
can claim that?

As for performance, I encourage you to take a look at the state of the art.
Working with our IO Monads has better performance than many abstractions that
people now take for granted, like most Future/Promise implementations.

I build systems that are super stressed by incoming traffic and Scala's
performance is awesome. Worse than bare metal Java of course, but when you
compare it with high level Java frameworks or with Python/Ruby/Javascript/what
have you, you'd actually be surprised by how better Scala FP is ;-)

As for Haskell, I like the language, but it's super fragmented, everyone has
its own Prelude and favorite language extensions, extensions that are
sometimes in conflict with other extensions and the tooling is a mess. Also
laziness is cool, but performance gets hard to predict. We have the same
problem in Scala when we are using lazy abstractions actually, the difference
being that Scala is opt-in instead of opt-out.

With Scala, even if you're targeting JS instead of the JVM, you still use the
same tools.

And I even like the language better. Scala 3 will fix many annoyances I have,
including adding untagged unions and GADTs that are based on ADTs, in other
words nicer than Haskell.

PureScript I would like though, as it fixes some of Haskell's problems, maybe
one day it won't be limited to JS.

~~~
dm3
> As for Haskell, I like the language, but it's super fragmented, everyone has
> its own Prelude and favorite language extensions, extensions that are
> sometimes in conflict with other extensions and the tooling is a mess. Also
> laziness is cool, but performance gets hard to predict. We have the same
> problem in Scala when we are using lazy abstractions actually, the
> difference being that Scala is opt-in instead of opt-out.

Not an expert in Haskell, nor Scala - only dabbling. However, the above could
be repeated verbatim after replacing Haskell with Scala, couldn't it? You can
write Java++, Haskell-- or any combination in between. Use one of the several
FP stacks or build tools.

I think both Scala, Haskell and C++ can compete for the name of the most
complicated, fragmented and diverse language and ecosystem in existence.

~~~
bad_user
I think people are too quick to judge languages.

If I tell you that Haskell has a fragmentation problem, I feel good about
telling you that because I actually have experience with it.

However Haskell is still a language that I'd pick over Java, Go, JavaScript or
any of the mainstream languages for that matter and I'd be willing to put my
reputation on the line for that choice.

I also worked with C++. To see people compare Scala and Haskell with C++, kind
of rubs me the wrong way.

And unfortunately such opinions stay on the Internet forever, are picked up by
beginners and repeated verbatim.

So no, there's a huge difference between Scala, Haskell and C++. For one the
former wouldn't lead to stupid and disastrous bugs like Heartbleed, whereas
C++ can and routinely does. By comparison when well typed Scala or Haskell
programs compile, the defect rate tends to be really low.

I'm seriously thinking about starting a course in how badly and easily you can
fuck up in C/C++, for people that make unfair comparissons with them, making
life hard for their managers :-)

Also just to get this out of the way... the problem in Scala are actually the
Java refugees going gung-ho on OOP. And the FP people, because they tend to be
more experienced, are the ones cleaning up the mess.

And I like that. You know why? Because Scala makes it possible to introduce FP
gradually, without an organization wide commitment. In the company I'm working
for, a language like Haskell would never fly, but Scala does.

Also in case you haven't noticed, FP is spreading.

\- in Typescript/JS you have fantasy-land and fp-js

\- in Kotlin you have Arrow

The difference is that you don't get the nice type system to support those
abstractions well, so you also get the weird HKT and type class encodings to
go with it. Although in fairness the Arrow guys are working on compiler
plugins for better supporting type classes and the HKT encoding that they use.

So if you're conservative about adopting FP, language choice will not really
protect you ;-)

~~~
dm3
Thanks for the answer.

To be clear, I wasn't comparing languages in terms of correctness of code you
could potentially produce. Of course C++ is the worst on this metric. However,
it has its own niche in low-latency setting where I can't see anything else
replacing C++ any time soon.

------
cmrdporcupine
This is interesting, and I could even see using it, though I haven't touched
Scala in 10 years... but I guess I wonder what the provenance of their GC is?
The JVM's has had three decades of tuning and optimization.

EDIT: I see Boehm and their own home grown. And a "none" which I can see being
useful if you have short running processes.

~~~
densh
0.3 has our own variation of Immix algorithm [1] [2]. On current development
snapshots we've also made it parallel and partially concurrent which is
expected to bring major speedups over previous single-thread implementation on
applications with medium to large-sized heaps [3].

[1]
[https://dl.acm.org/citation.cfm?id=1375586](https://dl.acm.org/citation.cfm?id=1375586)

[2]
[https://dl.acm.org/citation.cfm?id=2660198](https://dl.acm.org/citation.cfm?id=2660198)

[3] [https://github.com/scala-native/scala-
native/pull/1423](https://github.com/scala-native/scala-native/pull/1423)

------
xvilka
Still no 1.12[1] and 1.13[2] support, and many projects already migrated to
it. Upcoming 0.4.0[3] should solve both though. But seems like project suffers
from lack of developers.

[1] [https://github.com/scala-native/scala-
native/issues/233](https://github.com/scala-native/scala-native/issues/233)

[2] [https://github.com/scala-native/scala-
native/issues/1629](https://github.com/scala-native/scala-native/issues/1629)

[3] [https://github.com/scala-native/scala-
native/milestone/21](https://github.com/scala-native/scala-
native/milestone/21)

~~~
densh
> But seems like project suffers from lack of developers.

This is indeed the case.

------
mistrial9
uninformed question: is not The Driver for Scala to interact with Apache Spark
? Secondly, it seems from comments here that Scala -> JS is a thing, so that
is used for .. ? Third, is it the case that Scala 3 is taking the wind out of
Scala 2 improvements, and the dev community is small enough such that, that is
visible as 'not much happening' with Scala 2x ?

~~~
sjrd
> is not The Driver for Scala to interact with Apache Spark ?

A gateway drug? Perhaps. _A_ driver? Perhaps. _The_ only driver? Nope. For
example Scala is used a lot for regular Web servers.

> Secondly, it seems from comments here that Scala -> JS is a thing, so that
> is used for .. ?

* For the frontend of Web applications, notably because it allows reuse of code across client and server;

* For CLI applications based on Node.js (better startup time than with the JVM);

* For server apps based on Node.js (for people who like the Node.js ecosystem better than the JVM's, or who have an existing codebase to integrate with);

* For AWS Lambda apps (again, better startup time than the JVM);

* For mobile apps through React Native;

* For embedded applications, in cases where a JavaScript engine is available but no JVM;

* For browser extensions;

* For integration with any other kind of application that provides hooks in JavaScript (e.g., Google Sheets, see [https://medium.com/@antoine.doeraene/make-your-google-spread...](https://medium.com/@antoine.doeraene/make-your-google-spreadsheets-scala-ble-5695d9dd784f))

* etc.

> Third, is it the case that Scala 3 is taking the wind out of Scala 2
> improvements, and the dev community is small enough such that, that is
> visible as 'not much happening' with Scala 2x ?

No it is not the case. There are as many core contributors to Scala 2.x now
than there were before the Scala 3 effort was launched. And there are many
more external contributors, with numbers growing every year.

~~~
dwohnitmok
The machine behind Scala.js! Thank you for all you've done.

Out of curiosity, what remaining features/bug fixes are you planning to target
for v1?

~~~
sjrd
It's all in the issue tracker: [https://github.com/scala-js/scala-
js/issues](https://github.com/scala-js/scala-js/issues). Look for issues
attached to 1.x milestones.

------
melling
I briefly looked at Scala 9 years ago.

Where does one begin these days? My books are outdated?

Someone mentioned looking at Cats:

[https://typelevel.org/cats/](https://typelevel.org/cats/)

~~~
vturner
Does anyone think the coursera courses are worth it? I signed up and am
working through them in my free time.

~~~
mark_l_watson
I took Martin’s Scala class years ago and it was awesome. He is a great
lecturer.

