Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native v0.1

scala-lang.org

Post reply on HN
Print view View original

141–150 of 254 posts

Re: Scala Native v0.1

#141

Post by pjmlp »

chuwy wrote: post #17
LeanderK wrote: post #10

Earlier quoted context omitted.

I think for Server-Application Scala on the JVM will probably beat Scala-Native. The benefits of Scala-Native over Scala JVM are: - faster startup time - (drastically) lower memory footprint - fine hand-tuning of you application All these things are not super important in server-applications. For example Java trades memory for throughput (higher memory footprint, but also higher throughput. These usually go hand in h…

For me most important benefit is running without pre-installed VM. Not particularly important for backend, but huge win for user-space tools.

You could always bundle the jre, and with Java 9 one can even make use of the newly introduced linker to create a customized image just with the relevant classes.

Re: Scala Native v0.1

#142

Post by gravypod »

usrusr wrote: post #135
Recurecur wrote: post #129

Earlier quoted context omitted.

A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot. Nice handle BTW. lol

But how much predictability can you get in presence of garbage collection? Granted, the JIT can also be an element of surprise that is out of the picture with AOT and the statically linked GC can never be configured differently from what you expect, but it's still garbage collection and not Rust or a C.

There's a lot of examples of GC in realtime systems. It's just a different set of concerns. Rather then the programmer worrying about memory constantly, the compiler engineers are worrying about memory constantly.

This is a very fun read: http://www.flownet.com/gat/jpl-lisp.html

Re: Scala Native v0.1

#143

Post by kentosi »

This is extremely exciting. I can't wait to try this out.

On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

Re: Scala Native v0.1

#144

Post by LeanderK »

drkstr wrote: post #132
saosebastiao wrote: post #81

Earlier quoted context omitted.

This sounds like a plausible explanation, but is this verified/verifiable? Are there memory profilers that can show me the relative sizes of the young/old/permanent generation segments of the GC? I'm always blown away at the memory usage of JVM apps. Part of it is the fact that java has encouraged insanity-inducing inheritance hierarchies...but also it is incredibly hard to do dead code optimization on for such a sta…

Yes, it's called "perm gen cache," or something like that, on any standard JVM profile. This roughly represents the memory used by the type system. It can get pretty high if you are doing something like auto-generating types (GUI, build systems, etc)

perm gen disappeared on java 8 and i think the high memory demand for perm-gen was one of the reasons.

Re: Scala Native v0.1

#146

Post by keymone »

scotchmi_st wrote: post #116

I would love for there to be a similarly thorough project with Clojure. It really bothers me there's no good native compiler. Apart from anything else, it means that Clojure lives and dies by the languages it compiles to, and while Java is used everywhere still, it probably isn't the thing the kids are learning these days. Besides, without going into any further rational arguments for why using the JVM (or another VM…

one of Hickey's initial goals for Clojure was to be hosted language by design because .

still i agree with you, having native clojure would be amazing. there is pixie which is transpiled by rpython into c++ but it's pretty much abandoned.

Re: Scala Native v0.1

#147

Post by wtetzner »

kentosi wrote: post #143

This is extremely exciting. I can't wait to try this out. On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

There was RoboVM[1], but it looks like it shut down. GCJ [2] was GCC's Java implementation, which was natively compiled, but I think has been removed from GCC. I'm sure there are other projects.

[1] https://robovm.com/

[2] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java

Re: Scala Native v0.1

#148

Post by enjoiful »

At first glance of this article's title, I thought it would be a terrible idea to use Scala to write native mobile applications. Imagine using Scala.JS to write a NativeScript/React Native app. shutters

Re: Scala Native v0.1

#149

Post by dragonwriter »

mark242 wrote: post #71

This will be huge for getting Scala running on AWS Lambda. The cold-start times for JVM apps is just ridiculous and makes Lambda/API gateway essentially unusable for anything written on the JVM.

> This will be huge for getting Scala running on AWS Lambda.

Do you mean it might convince Amazon to add Scala as a supported language? You don't get access to run native code on AWS, just Python, Java, C#, or JS.

And, even with a robust, mature native implementation, I'm not sure that Scala would be the top priority for the next language.

Re: Scala Native v0.1

#150

Post by dragonwriter »

therealmarv wrote: post #5
gbersac wrote: post #3

That's a great news ! We are exclusively using scala at work for back end and I wonder if it could be interesting to switch new projects to scala native. Did you test scala native against well known and massive open source scala project ? Did the performance improved or regress ? Did you wrote a brand new scala compiler for native code ?

Never touch a running system ;) Scala on JVM is much more tested than the new shiny thing. Also don't expect improved performance... many people think that the JVM is bloated and makes programs slower (this is mostly not true). The downsides of the JVM are more memory consumption/footprint (when you have e.g. small servers or micro instances) and the cold startup time of the JVM itself (which is not relevant on a ser…

> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps).

With microservices run as containers that are started on demand it matters; with other architectural choices it may matter less.

Post reply on HN