Scala Native v0.1(scala-lang.org) |
Scala Native v0.1(scala-lang.org) |
I imagine building this stuff on Windows will be challenging :/
It is a problem that many compilers cannot be bootstrapped from source without a trusted binary of a previous release.
Is that such a big deal?
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.
is it a theoretical problem or a practical problem for industry users?
I thought the benefit/raison d'etre to Clojure is the JVM ecosystem.
Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)
The real benefit of native Clojure to me would be for reducing startup time and the JVM overhead in containers. The best option for this right now is CLJS, but it would be nice to just not have a runtime.
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.
* https://github.com/tptodorov/aws-lambda-scalajs
* http://underscore.io/blog/posts/2016/03/21/serverless-scale-...
I am excited that now there will be an option for getting both quick startup and fastest execution time!
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.
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 ?
I also did not get on well with the community, which seemed to have a lot of people with the attitude - "they won't let me use haskell at work so I'll make do with this shit". They didn't seem to understand or be interested in OO at all, and were very fanatical about driving application logic with types, purity, and the like.
Regardless, a native variant would be something well worth investigating if it ever reaches "production ready".
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?
Title says Kotlin, but it is about JVM languages going native, in general. Or should they?
The Java ecosystem is playing huge catch up here, and I don't think it's a bad thing that people are exploring alternatives, whether that's Avian, the now defunct RoboVM, or LLVM-based backends.
The only thing is that most ignore there is a JVM world outside OpenJDK.
And even those that know that world aren't willing to pay for commercial JVMs.
Thus propagating the myth that Java doesn't support AOT.
Which in a way is also understandable, given Sun's political decision that AOT compilation was tabu.
Luckily Oracle isn't Sun and has heard the industry. So if all goes as planned, by Java 10, those that don't want to pay for AOT compilers, will have one in OpenJDK.
I'm not a regular Scala user.
Quick question: does this compile down to DOT before going to LLVM? Or has DOT not yet arrived in Scala Native?
[1] http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.h...
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.
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 asm (or lib-less C) will consist largely of "non-helloworld code" in terms of "bytes occupied in the binary", right?)
Dunno might be of concern eg with embedded/raspberry and such, but for code to be "moved from a jvm-kinda flair to a go-kinda flair" I'm not seeing the issue .. yet ;)
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.
The goal was to create JVM suitable for standalone GUI applications. Project was abandoned when Sun/MS Java wars started in favor of the Sciter (https://sciter.com).
As of NativeScala ... I think that approach (binary with nano JVM + attached class files) may work better and with less effort. Scala needs JVM infrastructure, GC, etc. as far as I understand.
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.
On the other hand, the new targets (js and native) might make Scala more interesting to Java pragmatists who don't care much about going functional but would not mind writing Java in a more streamlined syntax.
People do [1], and are very happy with it.
Not sure if I get this, don't Java VMs support this use case (J2ME) ?
It must be frustrating to work on a project like this, see areas where the language can be improved, but only be able to do the work to make it purely compatible. Hopefully some good comes out in the form of some good SIPs.
On the other hand, it's also worth bearing in mind that this is version 0.1.0; over time, some of these limitations will lift. What i don't know is whether Scala Native will develop into a complete version of Scala which compiles to native code, or evolve into a variant of Scala more tightly adapted to a niche of talking to native libraries.
Anyway ...
(1) No threading [1]:
Scala Native doesn’t yet provide libraries for parallel multi-threaded programming and assumes single-threaded execution by default. It’s possible to use C libraries to get access to multi-threading and synchronization primitives but this is not officially supported at the moment.
So forget about using Akka for now.
(2) NullPointerExceptions are replaced with segfaults (hopefully) [1]:
A number of error conditions which are well-defined on JVM are undefined behavior: Dereferencing null. Division by zero. Stack overflows. Those typically crash application with a segfault on the supported architectures.
That's not so bad; where Java apps might let nulls flow around and rely on catching NullPointerExceptions to recover from them, Scala apps are much more likely to use Optional consistently.
(3) If you do want to talk to a native library, and you need to allocate memory to do it, you're on your own [2]:
Unlike standard Scala objects that are managed automatically by the underlying runtime system, one has to manage native pointers manually.
Scala Native provides a built-in way to perform stack allocations of unmanaged memory using native.stackalloc function: [...] When using stack allocated memory one has to be careful not to capture this memory beyond the lifetime of the method. Dereferencing stack allocated memory after the method’s execution has completed is undefined behaviour.
Scala Native’s library contains a bindings for a subset of the standard libc functionality. This includes the trio of malloc, realloc and free functions
Java's traditional JNI is a verbose, slow, pain in the stdout, but it was designed pretty carefully to avoid problems like this.
(a) Intermission! Check out how they do type-level numbers [1]:
Natural numbers are types that are composed of base naturals Nat._0, ... Nat._9 and an additional Nat.Digit constructor.
That's a new one on me!
(4) Incomplete JDK libraries [3]:
Scala Native supports a subset of the JDK core libraries reimplemented in Scala. Here is the list of currently available classes: [...] This is an ongoing effort, some of the classes listed here might be partially implemented.
The list has most of the fundamental stuff - a good chunk of java.io and NIO, the collections, java.lang, atomics. But no java.text, java.net, concurrency, regexp, date and time, JDBC, reflection, XML, etc.
They don't mention how much of the Scala libraries they support. I would imagine that they can build anything that's in pure Scala and depends only on JDK classes in that list, so you'll get the core language stuff and the collections. Not sure.
[1] http://www.scala-native.org/en/latest/user/lang.html
etc. etc.
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 platforms beyond the JVM.
What are the alternatives? I couldn't live without HKT these days (once you're used to thinking in them it's painful to work without them), which rules out most languages even in the ML space, and Scala has better IDE support than anything that's left (indeed an excellent tool ecosystem in general in terms of e.g. profilers, instrumentation) except possibly Ceylon (which doesn't have anything like the library/developer ecosystem of Scala). Even assuming Ocaml lands their modular implicits functionality doesn't change this as far as I can see.
Haskell is an option, but eager evaluation makes reasoning about performance much easier. (And I do think there are legitimate use cases for traditional OO inheritance, though this is debatable). If and when Idris reaches a similar level of library/tool support to Scala then it might become a better alternative to Scala Native, but not that many people are willing to use Idris in production yet.
To me, Scala's biggest benefits are just the language itself. So many little things that I couldn't do in Java, I can do with little effort in Scala. I can write imperative code if I really want, but I have all the benefits of functional programming available too.
While the VM in LLVM historically was short for Virtual Machine, it really has nothing to do with that. It's a compiler backend used by Clang (C++ compiler) and Rust.
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.
[1] http://www.scala-native.org/en/latest/user/lang.html#lang
With microservices run as containers that are started on demand it matters; with other architectural choices it may matter less.
- faster startup time
- (drastically) lower memory footprint
- fine hand-tuning of you application
- Predictable latency if desired (optional GC)
- Very low call overhead for C ABI
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-...
1) Much faster startup times
2) smaller memory footprint for small programs.
3) Potential for easier installation since no dependency on the JDK (assuming binaries are statically linked)
So basically you could use scala native to cover some cases that are better covered by golang or rust right now. For large and long-running server-side processes, the JVM is still king.
I think a lot of people see a dense 1-liner and panic when they can't read it as fast as a line of another language, when actually the same operation would be 5 or 10 lines in that other language. It's ok to take a bit longer to read it; in my experience if you take a deep breath and read slowly, breaking it down into pieces, it's all very simple - the combination may be complex, but everything is very modular and compositional so you can understand each piece in isolation and then put them together to make the bigger picture.
> I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler.
Do you still have it? Those are pretty rare (and almost always a type error rather than a correct type, though I appreciate that doesn't help you much at the time) and I'd be interested in minimizing it into an actual bug report.
> And the tools themselves were huge memory hogs
Yeah that does happen. I avoid SBT, but eclipse isn't exactly light. They're putting a lot more focus on performance in recent releases which will hopefully address this up to a point.
> I also did not get on well with the community, which seemed to have a lot of people with the attitude - "they won't let me use haskell at work so I'll make do with this shit". They didn't seem to understand or be interested in OO at all, and were very fanatical about driving application logic with types, purity, and the like.
The community is pretty awful. But I found that as people got more experienced, myself included, they tend more towards the pure, strongly typed side of things and make less and less use of OO. I understand OO but am no longer interested in it, and I think most experienced Scala folk feel the same way, so while the language does have good support for it, you'll struggle to find many people interested in helping you with it. I'm not sure anything can be done about this - you can't expect the experienced users to answer questions they're not interested in.
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.
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:
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!)
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.
The key advantage of Scala in general is that these things are rarely necessary - the fancy type system and generally expressive language make it much easier to address the use cases with "vanilla" Scala instead. So Scala Native will hopefully be able to bypass this issue.
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.
http://www.scala-native.org/en/latest/user/interop.html
>Scala Native provides an interop layer that makes it easy to interact with foreign native code. This includes C and other languages that can expose APIs via C ABI (e.g. C++, D, Rust etc.)
I've been playing with this and trying to convert a ~20 line helper script that I use at work (and would really like to benefit from no JVM warmup time), and I've already run into missing core library functions like parallel collections and regexes.
This thing will be really great when it's ready, but it's not even close yet.
That's what I thought.. another C-based FFI. Better than nothing, I suppose.
It's at least a dozen people who should be credited, even if I'm currently the only one paid for this work.
Does Scala Native support not using a GC? It seems like it would be difficult to get Scala working without a GC.
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
@extern object stdlib {
def malloc(size: CSize): Ptr[Byte] = extern
}
val ptr = stdlib.malloc(32)
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."A lot of the extra memory usage of Java apps comes from sloppy programming and from depending on lots of heavyweight libraries and frameworks.
https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
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.
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.
I still hate JS though.
(Though, I tend to share the annoyance of javascript...)
Everything is relative. Scala.js remains significantly slower than Scala/JVM in terms of throughput.
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
For both you need:
* An understanding of what kind of code will be generated
* Predictable, and hopefully verified, GC
* Reasonable binary sizes
* Very good tree shaking
If Scala Native could deliver on small binary sizes, "0 runtime" like Rust, and a way embed inline assembly like instructions then it would be a winner.
This is a very fun read: http://www.flownet.com/gat/jpl-lisp.html
Edit: thanks for the downvotes but you could at least tell me what's so crazy about my statement.
At work I'm running 17 different containers- many of which require their own JVM. (That's 3 different JRuby apps, zookeeper, kafka, and ElasticSearch.)
Those JVMs get heavy when you're shipping container images compared to small Go or Rust binaries.
Rather than fix Confluence to work on OpenJDK (I don't want to imagine what type of reflection garbage they've got going on down there that breaks so bad on OpenJDK), their instructions tell you how to make your own Dockerfile using the official Oracle runtime.
Actually, in that situation, if it won't run on OracleJDK it's probably not going to work via a native compiler either.
I'd love it if I could compile those options into a binary.
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:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dkafka.logs.dir=/opt/kafka_2.11-0.10.0.0/bin/../logs -Dlog4j.configuration=file:bin/../config/log4j.properties -cp :/opt/kafka_2.11-0.10.0.0/bin/../libs/aopalliance-repackaged-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/argparse4j-0.5.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-api-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-file-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-json-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-runtime-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/guava-18.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-api-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-locator-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-utils-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-annotations-2.6.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-core-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-databind-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-jaxrs-base-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-jaxrs-json-provider-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-module-jaxb-annotations-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javassist-3.18.2-GA.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.annotation-api-1.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.inject-1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.inject-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.servlet-api-3.1.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.ws.rs-api-2.0.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-client-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-common-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-container-servlet-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-container-servlet-core-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-guava-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-media-jaxb-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-server-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-continuation-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-http-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-io-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-security-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-server-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-servlet-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-servlets-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-util-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jopt-simple-4.9.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0-sources.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0-test-sources.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-clients-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-log4j-appender-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-streams-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-streams-examples-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-tools-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/log4j-1.2.17.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/lz4-1.3.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/metrics-core-2.2.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/osgi-resource-locator-1.0.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/reflections-0.9.10.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/rocksdbjni-4.4.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/scala-library-2.11.8.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/scala-parser-combinators_2.11-1.0.4.jar:/opt/kafka_2.11-0.10.0.0/bin/../lib
The rest of the arguments are about GC tuning and logging. How would you do those things in a language that gives you a "simple" static binary? Either you can't at all, or they'd require an equally complex series of arguments.
That most don't want to pay for them is another matter.
The only differences between C and a powerful macro assembler like MASM, is that C is portable across CPU architectures and exposes less internals.
Rock solid?
With all the UB that Assembly actually doesn't have, and the types of memory corruption issues shared with Assembly programming, not really.
Taken to the extreme, any language ultimately goes down to machine code. So if it was a relevant fact, it would be relevant for all languages.
There are strong typed assemblers, e.g. IBM i.
Also Assemblers don't remove code under your feet, like optimizing C compilers with their UB tricks happen to do, introducing security bugs.
The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.
* 21% memory footprint reduction
* 27% less GC
* 5% throughput improvments
This sounds like a very Erlang-ish way to handle the problem. Another advantage is that if the server/process is in some weird state that's causing problems, killing and restarting it lets you clear out the broken state, and get back into the state that it's most likely been tested under.
Lost connectivity to RabbitMQ or Elasticsearch would mean our site is dead anyhow (you can't do anything). So either of those errors should arguably result in some static 500 pardon-our-appearance page.
But say someone messes up the network connection or we get a brief problem.
Why wouldn't the nodejs process start quickly?
It's a pity that so few Java projects have tried to use these mechanisms without building them as part of massive frameworks, sometimes apparently even without understanding what they have built.
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.
We run our Scala apps on Aurora/Mesos behind a load balancer (hundreds of instances for just one app). If there's an issue that can't be handled within the app and error rates breach a given threshold, Aurora just kills the instance and creates a new one on another host.
1. What should the default be? Java build systems default to building dynamically linked, though it's a few lines to change. IMO dynamic is a better default for large projects, as you usually have more library modules than executable modules. On the other hand a large project is likely to already involve a fair bit of build config, so maybe the defaults should be optimized for small projects.
2. Whether you allow dynamic at all. To my mind it's always worth having the option, and I think Go will come to regret not having it if and when it ever gets used for large projects.
As of Go 1.8 it also provide plugin support though I am not sure if they are any where near Java in term of dynamic libraries loading support.
I bet if something like RubyMotion wasn't a commercial product, the reality would be quite different.
Don't believe what you read, especially when it originates from a biased source.
When i want productivity, i use python.
When i want speed, i use c.
When i want both, i use both.
(I've used "java -jar myapp.jar" in production and it's been fine; the Java mainstream may favour using lots of -Dblah but it's entirely possible to replace that with code)
Just wait and it will come, it only needs a bit of enterprise architecture caretakers.
JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.