Live data from Hacker News

Scala Native with Denys Shabalin – Software Engineering Daily Podcast

softwareengineeringdaily.com

11–20 of 42 posts

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#11
post #9

Earlier quoted context omitted.

JVM startup is really painful for short to medium time running apps, this is the niche we’re trying to address.

I meant, "compile bytecode to machine code." The fact that nobody does it is a sign that it's not a good idea. I guess I was just wondering why.

Scala is a relatively simple language in the end of the compiler pipeline. We just take lowered ASTs and emit our SSA representation from there because it’s easy it to implement it this way. You can totally do something similar from the bytecode.

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#12
post #9

Earlier quoted context omitted.

JVM startup is really painful for short to medium time running apps, this is the niche we’re trying to address.

I meant, "compile bytecode to machine code." The fact that nobody does it is a sign that it's not a good idea. I guess I was just wondering why.

Excelsior JET does it, and it works Scala. So you can already compile JVM targeted Scala to native code that way if you want to. JET is fairly expensive, though.

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#16
post #9

Earlier quoted context omitted.

JVM startup is really painful for short to medium time running apps, this is the niche we’re trying to address.

I meant, "compile bytecode to machine code." The fact that nobody does it is a sign that it's not a good idea. I guess I was just wondering why.

Lots of people do it.

Besides ExcelsiorJET named in a sibling answer, the JDKs from Aicas, IBM, PTC, STMicroelectronics, Google with their ART implementation and a few smaller vendors for the embedded market.

Also Oracle just added initial AOT on Java 9, with plans to extend it to other platforms, and eventually (long term plan) rewrite everything in Java as part of Project Metropolis.

Oracle also had AOT compilers before Sun's acquisition, like JServe and JRockit.

Why does it seem no one does it?

Sun was religiously against AOT, leaving it to third party commercial vendors.

And since the rise of FOSS most developers think it is outrageous to pay for compilers, only Fortune 500s buy such compilers.

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#17

Any reason to use Scala native when Rust exists?

The language is more powerful, Rust still doesn't have HKT support.

The maturity of the eco-system.

Not having to deal with the borrow checker.

In any case, I would say in such cases OCaml and Haskell are also good candidates.

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#19

I remember that shortly after??? Scala native was first announced, Kotlin native made the news. How do these two compare today? Which one is better suited to create native executables now?

The alternative Kotlin compilers are currently at the "proof of concept" stage, but aren't usable, or supported much by the community.

Scala's JavaScript compiler (http://www.scala-js.org/) on the other hand is production ready and supported by the whole ecosystem, with plenty of libraries being cross-compiled to both the JVM and JS.

Scala Native piggybacks on top of the work made for Scala.js — it's harder, due to not being able to piggyback on another platform this time, so they have to deal with things like concurrency or garbage collection, but it's progressing nicely.

Scala Native isn't production quality yet, but it's at that stage where it's fun to play with it and the Gitter channel has some friendly folks you can interact with: https://gitter.im/scala-native/scala-native

Re: Scala Native with Denys Shabalin – Software Engineering Daily Podcast

#20
post #17

Any reason to use Scala native when Rust exists?

The language is more powerful, Rust still doesn't have HKT support. The maturity of the eco-system. Not having to deal with the borrow checker. In any case, I would say in such cases OCaml and Haskell are also good candidates.

Rust is in a different league altogether.

Scala, Haskell, OCaml are garbage collected languages. This makes them easier to use, but some problems are out of reach.

Embedded development, kernels, native apps requiring performance without frames dropped, real-time systems actually, including consumer stuff like decoding video, these have been the domain of C/C++.

Of course, there are projects out there using these languages, pushing the boundaries, like MirageOS (https://mirage.io/) which is built with OCaml. But those are like the exceptions confirming the rule.

Post reply on HN