Possible with GraalVM. Has been possible if you were willing to pay long before that. GraalVM produces statically linked binaries with only one external dependency — zlib, which is preinstalled pretty much everywhere. Startup time is measured in milliseconds.
I recently built a mid-size REST backend with quarkus — it ships as a single binary with size comparable to what I'd expect to see if it was written in Go, and starts in about 200 ms (from executing the command to when it's ready to serve its first request).
Having written code in both, I hope GraalVM buries Go in the long term, but in our hype-driven culture it's unlikely.
https://quarkus.io/guides/building-native-image#configuring-...
https://github.com/oracle/graal
> A reasonably good and ergonomic concurrency approach (like JS, unlike Java)
This is also very close to being solved.
[1] https://github.com/oracle/graal
[2] https://github.com/babashka/babashka
[3] https://arnoldgalovics.com/java-cold-start-aws-lambda-graalv... (large proj - dynamoDB)
[4] https://dev.to/wololock/groovy-script-startup-time-from-2-1s... (small proj)
Here's the heap implementation, for example: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
The GraalVM is a Java implementation of the Java compiler and VM and it's also on GitHub: https://github.com/oracle/graal
https://github.com/oracle/graal
It's not even a mono-repo - this is just part of the project.
Maybe someone's got some tools that let them dig around in the history and find large things or explain why it's so large? I don't think they've been checking ISOs in.
> GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Clojure, Kotlin, and LLVM-based languages such as C and C++.
and yes, it can do interop between those languages
The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis.
As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System.
Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,....
IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability.
While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.
It is true that GraalVM has a proprietary version too, that AFAIK has extra features, but the open source version is impressive on its own.
What developers really need to do is to stop building on platforms based on how much they like a company. Stop treating companies like sports teams. Your feelings for a company are completely irrelevant because its culture can always change, or it can be sold to the highest bidder.
Things that matter much more:
1. Is it Open Source? This is important for having control. E.g. no matter what Oracle does next, there is now a community dedicated to maintaining and improving OpenJDK and in fact OpenJDK has cool features that Oracle’s Java does not, like a cool new low latency GC contributed by Red Hat.
2. Does it have an ecosystem around it?
GraalVM is new, but it piggybacks on Java’s ecosystem and Java is huge. In fact that’s also why Google piggybacked on Java too.
Speaking of which, I’m not defending Oracle’s lawsuit, I think they did it because they are greedy bastards, however the elephant in the room is that Google fragmented the Java ecosystem.
It is 2019 and Android’s SDK still does not support Java 8’s bytecode.
So how is Google any more special than Microsoft and what they did with Java (J++) back in the day? I don’t see a difference. And now the Java ecosystem can’t move on to Java 8 due to Android.
We have a huge double standard. Back in the day when Sun sued Microsoft people cheered for Sun.
Sure. That doesn't change my statement though.