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

61–70 of 254 posts

Re: Scala Native v0.1

#61

Post by meddlepal »

sreque wrote: post #34
cwyers wrote: post #29

It seems to me like Scala's biggest benefit and biggest downside are two sides of the same coin: easy interop with the JVM and Java code. Scala Native just seems like you're paying all the price of that for none of the benefit.

I think the Scala community's aims have been higher than what you've suggested for a while. For example, from what I've seen, Scala.js has been wildly successful, yet according to you it should never have existed. Scala.js lets you run Scala code on javascript-based VM's and provides full integration with the underlying platform and libraries. Scala native looks to be another attempt to expand Scala's reach into new…

Define "wildly successful"... I can't name a single company or project that uses Scala.js.

Re: Scala Native v0.1

#62

Post by 0xFFC »

so dream comes true!

P.S. I think this is related to rust, in a sense before Rust there was no serious competitor to C/C++, but after seeing what Rust doing to C/C++ I think there will be more native language to compete with in low level area.

Re: Scala Native v0.1

#63

Post by algesten »

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).

I disagree somewhat with this.

We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling.

For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, than try to construct reconnect logic.

The problem with reconnect-logic is that it is code that (may) be tested very rarely. This in turn means it's easy to get strange long term problems there like very slow memory leak due to some listener being added to a connection object once the connection is initiated.

We did a 180 on reconnect-logic in our nodejs-processes and let the exceptions just bubble unhandled and take the entire vm down. With automatic restart script, the process will be back in seconds anyway, and with docker having built in back-off timers for auto restart, we don't necessarily overload the shared resources.

Re: Scala Native v0.1

#64

Post by usrusr »

dualogy wrote: post #36
gravypod wrote: post #31

Does anyone have any example binaries compiled with this? What are the sizes that you could expect? They say one of their targets is using this for command-line tools (I'm guessing for startup speed and needing to be small in memory footprint) but it's not of much value if an "echo" or "grep" implementation takes up 15 to 30MB on the drive.

> but it's not of much value if an "echo" or "grep" implementation takes up 15 to 30MB on the drive In this day & age? It might be of value if an echo or grep takes ~20MB and a full-blown HTTP REST server with DB access takes ~25-30MB. Why do I care again exactly whether there is a fixed portion of bootstrap/runtime core code in the binary, as long as I'm not writing echo or grep? (Any helloworld app not written in a…

When you are writing that full-blown HTTP REST server with DB access you would probably be served better on the JVM. Scala native is just as garbage collected as Scala JVM and garbage collection is where the JVM shines brightly.

In my eyes, the main value proposition of Scala native will be "you don't have to learn a new language if you need to write an echo or a grep", with "you don't need to learn a new language if you need to run some of your code on a platform that does not have a reasonably good JVM" a distant second. The former would suffer a lot from oversized binaries, the latter depending on the specifics of the target environment.

Re: Scala Native v0.1

#65

Post by trueSlav »

meddlepal wrote: post #61
sreque wrote: post #34

Earlier quoted context omitted.

I think the Scala community's aims have been higher than what you've suggested for a while. For example, from what I've seen, Scala.js has been wildly successful, yet according to you it should never have existed. Scala.js lets you run Scala code on javascript-based VM's and provides full integration with the underlying platform and libraries. Scala native looks to be another attempt to expand Scala's reach into new…

Define "wildly successful"... I can't name a single company or project that uses Scala.js.

I heard about it for the first time today and I tend to check on the JS framework ecosystem periodically...

Re: Scala Native v0.1

#66

Post by chrisseaton »

krenoten wrote: post #55
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…

Servers very frequently benefit from lower memory footprints, as it can also dramatically improve performance by improving cache efficiency.

The large memory footprint of the JVM is memory for classes, profiles, things like that. Those are used to create optimised code and to recover when optimisations were too optimistic. When your program is optimised and running in steady state, this memory isn't actively used and so doesn't contend with your application memory and so has no impact on cache efficiency.

Re: Scala Native v0.1

#68

Post by geodel »

sreque wrote: post #16
therealmarv wrote: post #12

Earlier quoted context omitted.

But can be important if you only have a 512MB DigitalOcean instance or using small Linux containers/Docker.

The JVM itself doesn't add a huge memory footprint. I remember Charles Nutter of JRuby fame calling it the "20-30 MB memory tax" (see http://blog.headius.com/2008/11/noise-cancelling.html ). A lot of the extra memory usage of Java apps comes from sloppy programming and from depending on lots of heavyweight libraries and frameworks.

If you include idiomatic Java programing as part of sloppy programming I also agree with that.

https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...

Re: Scala Native v0.1

#69

Post by mason55 »

algesten wrote: post #63
therealmarv wrote: post #5

Earlier quoted context omitted.

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). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…

I guess I don't see the difference here if your VM startup time is 3 seconds or 15-30 seconds. If that's the difference between the site remaining stable and the whole thing collapsing then it seems like you're setting yourself up for a big outage one day when the nodejs process isn't able to come back in three seconds for whatever reason.

Re: Scala Native v0.1

#70

Post by geodel »

meddlepal wrote: post #61
sreque wrote: post #34

Earlier quoted context omitted.

I think the Scala community's aims have been higher than what you've suggested for a while. For example, from what I've seen, Scala.js has been wildly successful, yet according to you it should never have existed. Scala.js lets you run Scala code on javascript-based VM's and provides full integration with the underlying platform and libraries. Scala native looks to be another attempt to expand Scala's reach into new…

Define "wildly successful"... I can't name a single company or project that uses Scala.js.

Perhaps it could mean successful in wilderness not in typical companies etc.
Post reply on HN