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.
Does it really need to be a binary? Build executable jars (use the maven shade plugin), run them with java -jar foo.jar, that's about as simple as it gets.
Maybe some apps do not have classpath. Here is what I see of running kafka instance on one of my server. And it does not looks like as simple as it gets. java -Xmx512M -Xms512M -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true -Xloggc:/opt/kafka_2.11-0.10.0.0/bin/../logs/zookeeper-gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateSt…
It's a few lines of code to get sbt to combine everything into a single jar. Do other languages not requiring including libraries?
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 ?
Scala is a language I desperately wanted to like - high level, statically typed pure OO language. But in practice I found it almost unusable. The type signatures were unreadable and I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler. And the tools themselves were huge memory hogs - sbt was a particularly bad offender (though otherwise quite pleasant). I also did not…
It looks like you dislike the haskell like usage of Scala, I wonder how could you then produce types so complicated/weird that you crashed the compiler in 100 lines (In 4 years I have seen it crash only once in an unreleased version of pickling a long time ago).
Scala is a language I desperately wanted to like - high level, statically typed pure OO language. But in practice I found it almost unusable. The type signatures were unreadable and I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler. And the tools themselves were huge memory hogs - sbt was a particularly bad offender (though otherwise quite pleasant). I also did not…
It looks like you dislike the haskell like usage of Scala, I wonder how could you then produce types so complicated/weird that you crashed the compiler in 100 lines (In 4 years I have seen it crash only once in an unreleased version of pickling a long time ago).
I never claimed my criticism was fair or consistent :P I think I was more interested in Haskell-like type driven programming at the time though. I honestly can't remember what it was.
And it's not so much that I hate type driven programming or purity. I just view them as tools in my toolbox, not as methodologies or worse - religions. I still think objects are an amazing concept if you look at them through the smalltalk lens. Or if you take a moment to step back and realise that an anonymous function is very similar to an object with an "apply" method, or that a constructor for an immutable object is like a functor that partially applies many related functions at once.
Long time Java lover here. I agree with all your points, but in the context of Java at least (does Scala support this?) there is no simple static binary that can be built and released, which includes the JVM. I think 1.9 will have this option, but this is something I didn't realize I missed until I started work with Rust and Go. It makes deployment so much simpler.
Does it really need to be a binary? Build executable jars (use the maven shade plugin), run them with java -jar foo.jar, that's about as simple as it gets.
I have never successfully deployed a Java application with defaults on the GC, etc.
I'd love it if I could compile those options into a binary.
It looks like you dislike the haskell like usage of Scala, I wonder how could you then produce types so complicated/weird that you crashed the compiler in 100 lines (In 4 years I have seen it crash only once in an unreleased version of pickling a long time ago).
I never claimed my criticism was fair or consistent :P I think I was more interested in Haskell-like type driven programming at the time though. I honestly can't remember what it was. And it's not so much that I hate type driven programming or purity. I just view them as tools in my toolbox, not as methodologies or worse - religions. I still think objects are an amazing concept if you look at them through the smallta…
In my opinion you are mostly describing Scala. Mutability and impurity is trivially easy to do in Scala. You may see that as a positive or a negative. Local mutability is definitely easier. Complexity of Scala comes from mixing OO and FP worlds and I think it's an amazing engineering feat. It will undoubtedly look ugly after you do Haskell though.
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
Codename One predated RoboVM, was always larger and is still open source and well supported: https://www.codenameone.com/
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. Sec…
For mobile all of these don't apply. The mobile version of Java doesn't include as much dynamic stuff and doesn't require dynamic loading so you can build a really efficient AoT compiler e.g. https://www.codenameone.com/
The core JDK makes those assumptions and is indeed a bad candidate for AoT OTOH so is scala and it will prove very difficult to provide any value beyond what the JDK already offers.
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…
Scala (and Java itself) are much easier to build native compilers for than Clojure, where numerous values are actually small dictionaries, nothing has a fixed type, and a large amount of the code is expanded from macros that are expecting to executing in the environment of deployment (not some special compilation stage). It is a language that essentially needs a heavy runtime to be remotely efficient (as anything super small is going to be rather equivalent to a barebones/naive JavaScript implementation), and it is unlikely that an attempt to build out a nice runtime for it is going to somehow be extremely better than the JVM (or a JavaScript engine, which might be even better in some ways).