Live data from Hacker News

Scala Native with Denys Shabalin – Software Engineering Daily Podcast

softwareengineeringdaily.com

31–40 of 42 posts

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

#31
post #6

Why would you compile Scala natively itself instead of compiling JVM bytecode?

Scala may be written in functional style, which is a poor match for JVM (e.g.: uglyness of `@tailrec` annotations, absence of mutually-recursive functions, JVMs GCs are not usually optimized for that many ephemeral objects, etc).

Native code is not much better as a compilation target for FP, but at least you don't have to fight through JVM constraints first (GHC compiles to pretty efficient native code).

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

#32
post #14

Still requires Java to build.

Yes, that is true but eventually this could be lifted. There is ongoing work getting the compiler compiled with Scala Native as well as other work related to pulling the code related to build out of the sbt build that requires the JVM. This could make a native build chain possible.

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

#33
post #32
post #14

Still requires Java to build.

Yes, that is true but eventually this could be lifted. There is ongoing work getting the compiler compiled with Scala Native as well as other work related to pulling the code related to build out of the sbt build that requires the JVM. This could make a native build chain possible.

Those are great news, thank you!

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

#34
post #9
post #6

Why would you compile Scala natively itself instead of compiling JVM bytecode?

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

How about generating .so, callable from other environments, for example CPython?

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

#35
post #24

Earlier quoted context omitted.

The only competing production-capable languages are Haskell, OCaml, and maybe F#

I'd include Rust on your list (if we're defining production-capable at a level where Scala Native qualifies), and maybe even Idris. I do think Scala still has advantages: higher-kinded type support which OCaml and F# don't have, strict evaluation unlike Haskell, and better IDE/tool support than any except F#.

I wouldn't say Idris is "production ready" in terms of libraries and tooling. Unless dependent types is a must, I would choose Purescript instead if I wanted something Haskell'ish but strict and with nice JavaScript support.

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

#36
post #34
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.

How about generating .so, callable from other environments, for example CPython?

This is on our roadmap, stay tuned.

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

#37
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.

Powerful is a strange choice of word. Did you meant to say more expressive?

I feel like if anything, Rust sounds more powerful to me, greater performance, control over memory, low level unsafe access, etc.

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

#38
post #16

Earlier quoted context omitted.

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 b…

Are they all proprietary/closed-source? When I was first learning about Clojure I really wanted a native JVM compiler, but as a hobbyist I was not about to go all-in on an enterprise compiler. The only FOSS solution I found was GCJ.

That, and "the JVM startup is slow!" seems to be a popular argument against Clojure and Scala here on the Intertubes.

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

#39
post #35
post #24

Earlier quoted context omitted.

I'd include Rust on your list (if we're defining production-capable at a level where Scala Native qualifies), and maybe even Idris. I do think Scala still has advantages: higher-kinded type support which OCaml and F# don't have, strict evaluation unlike Haskell, and better IDE/tool support than any except F#.

I wouldn't say Idris is "production ready" in terms of libraries and tooling. Unless dependent types is a must, I would choose Purescript instead if I wanted something Haskell'ish but strict and with nice JavaScript support.

Is PureScript really any more production-ready than Idris? That wasn't the impression I got.

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

#40
post #39
post #35

Earlier quoted context omitted.

I wouldn't say Idris is "production ready" in terms of libraries and tooling. Unless dependent types is a must, I would choose Purescript instead if I wanted something Haskell'ish but strict and with nice JavaScript support.

Is PureScript really any more production-ready than Idris? That wasn't the impression I got.

It seems a bit more mature, at least in terms of package management and available libraries (https://pursuit.purescript.org). I'm not very impressed with the editor/IDE support though.
Post reply on HN