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

151–160 of 254 posts

Re: Scala Native v0.1

#151

Post by nakkaya »

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…

I maintain a project called Ferret [1], which compiles a subset of Clojure to C++11. No VM no dependencies you get a single cpp file that can be compiled to native code. Supports any platform with a C++11 compiler. (atmega, arm, x86 etc.)

[1] http://ferret-lang.org/

Re: Scala Native v0.1

#152

Post by david-given »

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?

Would this be a good time to mention that a few years ago I wrote an experimental Java AOT compiler which worked by converting bytecode into C++?

http://cowlark.com/cowjac

I used Apache Harmony as the standard library, and binaries were about 2MB, which back in 2012 I considered unacceptably large; benchmarks were adequate only. I never got round to implementing a garbage collector but the hooks were in place for a simple mark/sweep stop-the-world collector. The hard part would be to actually make all threads of the program stop so they could be collected; I had a plan, but no implementation.

Interested parties may also be interested in my experimental Java JIT which worked by converting bytecode into Lua and then running it with LuaJIT:

http://cowlark.com/luje

It actually beat OpenJDK Server for some unrepresentative microbenchmarks. It's very unfinished, and generates fairly pathological Lua code which LuaJIT has trouble with, but the biggest problem is that Lua and LuaJIT can't do shared-memory threading, so most Java code won't work on it.

(JVMs are surprisingly easy to write. If you're interested in interpreters or code generation, I encourage you to try it.)

(Man, I completely forgot I wrote these until now!)

Re: Scala Native v0.1

#153

Post by rekado »

ajross wrote: post #82
rekado wrote: post #79

Unfortunately, this requires an existing Scala compiler to build, so it won't be useful as a bootstrap compiler for Scala on the JVM. Does anyone here know of an alternative implementation of Scala that could be used to build the libraries and tools of the reference implementation from source? It is a problem that many compilers cannot be bootstrapped from source without a trusted binary of a previous release.

It's a universal truism that all compilers cannot be bootstrapped from source without a trusted binary. It's true that in the world of standardized languages (which mostly means "C" in practice) there are compilers (mostly just gcc and clang) that can bootstrap themselves with a trusted binary of a previous release of some other compiler. Is that such a big deal?

I wrote "a trusted binary of a previous release" not just "a trusted binary". There is obviously a difference between having a small set of trusted binaries to bootstrap and having a bootstrap binary for every language or build system.

There are several compiler implementations that enable bootstrapping from alternative implementations, which shifts the problem to a simpler language, which may already have a bootstrap path.

See also http://bootstrappable.org/best-practises.html

Re: Scala Native v0.1

#154

Post by algesten »

mickronome wrote: post #126
algesten wrote: post #63

Earlier quoted context omitted.

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

The most effective way to handle these kind of errors in Java unfortunately requires understanding class loading, thread contexts, wrapping connection primitives in the right kind of references, and then making sure that all resource deallocation/closing always use the same codepath. Even though you really only need to implemnt it once, it is both somewhat tricky and technically challenging. It's a pity that so few J…

Yes, I did spend large parts of my java developer looking at class loaders and class loading delegations in servlet containers etc.

I think it's a bit too hard to get it right.

Like, suddenly some third party library starts pulling in log4j and your whole logging setup goes wrong in subtle yet very bad ways.

Or you screwed up with that one reference to a ResultSet and even though it is closed, that reference keeps an entire class tree of Connection, PreparedStatement etc alive.

Re: Scala Native v0.1

#155

Post by eikenberry »

dragonwriter wrote: post #149
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.

You can run native code on AWS Lambda. It just isn't officially supported. See Apex for an example of how to get it working..

https://github.com/apex/apex

Re: Scala Native v0.1

#156

Post by emmelaich »

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…

Forgive my ignorance, but wouldn't one of the existing Schemes be a better or as good option?

I thought the benefit/raison d'etre to Clojure is the JVM ecosystem.

Re: Scala Native v0.1

#157

Post by [deleted] »

rekado wrote: post #79

Unfortunately, this requires an existing Scala compiler to build, so it won't be useful as a bootstrap compiler for Scala on the JVM. Does anyone here know of an alternative implementation of Scala that could be used to build the libraries and tools of the reference implementation from source? It is a problem that many compilers cannot be bootstrapped from source without a trusted binary of a previous release.

[deleted]

Re: Scala Native v0.1

#158

Post by twic »

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?

It was. Several times.

It didn't take off for two reasons.

Firstly, it's not really any faster than a good JIT, and Java has very good JITs. The startup time is better, but the startup time of a JVM itself is actually pretty small ('time java -cp . HelloWorld' prints 'real 0m0.112s' on my machine), and for the uses Java is usually put to, irrelevant. I'd be very interested to see some benchmarks for Scala Native.

Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM.

Re: Scala Native v0.1

#159

Post by twic »

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…

A JVM boots in about 100 milliseconds. A difference of 100 milliseconds made the difference in how you do error handling?

Re: Scala Native v0.1

#160

Post by jwdunne »

pjmlp wrote: post #139
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…

> isn't the thing the kids are learning these days Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.
Post reply on HN