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.

True, and if you wouldn't have to worry about Oracle licensing either (although you can avoid that currently with OpenJDK as well)

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.

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 static (type and compilation model) language (I blame dymanic classloading, but that's more of a guess than anything). Maybe what you're saying is the reason we don't see noticable GC pauses until you start seeing large amounts of data...but it is still a huge pain for low memory environments like phones, embedded devices, IoT, etc. And while memory usage is always gonna be higher on a GC'd language, the JVM still consumes vastly more memory than other languages like OCaml, D, Go, etc.

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.

In general (not for server apps), two major benefits of Scala Native are:

  - Predictable latency if desired (optional GC)
  - Very low call overhead for C ABI

As to your point about memory use, Java trades memory for convenience, not performance. GC requires substantially more memory for similar performance. I read an IBM blog (which I can't find at the moment) within the last week which showed a Swift web service running slightly faster than Java, but using only half the memory.

The following comparison is also interesting, with a JSON serialization example in Swift outpacing Spring/Java by a factor of ten... This is also running on Linux instead of macOS.

https://medium.com/@qutheory/server-side-swift-vs-the-other-...

The medium post is really a stupid benchmark. Check this for a real JSON serialization benchmark - https://www.techempower.com/benchmarks/#section=data-r13&hw=...

To be fair, in that list, the spring entry didn't exactly run circles around the competition either. It's somewhere between the better PHP contenders and even behind grails (which can be pretty accurately described as spring with layer of slowness added on top). Really looks like there is something unfortunate going on with the idiomatic way to implement those examples on spring.

> Predictable latency if desired (optional GC)

Does Scala Native support not using a GC? It seems like it would be difficult to get Scala working without a GC.

It supports direct allocation via both the heap and the stack.

  type Vec = CStruct3[Double, Double, Double]

  val vec = stackalloc[Vec] // allocate c struct on stack
  !vec._1 = 10.0            // initialize fields
  !vec._2 = 20.0
  !vec._3 = 30.0
  length(vec)               // pass by reference

...and...

  @extern object stdlib {
    def malloc(size: CSize): Ptr[Byte] = extern
  }

  val ptr = stdlib.malloc(32)

http://www.scala-native.org/en/latest/

Otherwise it currently uses the Boehm GC.

One big area that needs more work:

  "Scala Native doesn’t yet provide libraries for parallel
   multi-threaded programming and assumes single-threaded    
   execution by default."

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

I used the JVM on the 512MB DO instances and containers and they run fine. I think for containers there are other issues (most likely you are going in a micro service-direction where latency is eventually going to be important, so picking another JVM GC-algorithm might be suitable). There may be applications for which the 512 instances and JVM are not suitable, but you can most likely just upgrade the instance.

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

Many things pointed out in this article apply to just about every managed language runtime. Implement a TreeSet in any language and you'll see the same overhead from object headers, memory alignment, etc. Java has some oddities that cause it to waste extra memory, but off the top of my head the only I can think of is 16-bit character Strings. Java 9 is supposed to help with that by allowing Strings to internally store utf8 characters.

I do like the slide though showing that people tend to assemble abstractions together and completely lose sight of the performance costs of what they are doing. There's also the fallacy commonly held by many that because someone took the time to write a framework or library, they must have also taken the time to ensure it's optimized well.

Go uses quite a bit less memory than Java.

http://benchmarksgame.alioth.debian.org/u64q/go.html

As per the Specjbb benchmark, JDK9 compact strings optimization itself provides,

  * 21% memory footprint reduction
  * 27% less GC
  * 5% throughput improvments

https://www.infoq.com/presentations/java-se-9-cloud - check this presentation for more details.

Impressive numbers.

Due to value types support, which are part of Java 10's roadmap.

I'd imagine it will be at least 5 years away when most popular Java software use this feature and java users see the effect of this.

Don't forget the ability to distribute binaries. This could be really nice for in-house tools.