If you're interested in stuff like this for go, I've used https://github.com/GeertJohan/go.rice with great success.
[EDIT]
"feature" -> "side effect"
"rust and golang" -> "rust and golang being able to produce static binaries"
For example, you can do the import with gcc this way: https://balau82.wordpress.com/2012/02/19/linking-a-binary-bl...
With Green Hills, there is a .rawimport directive.
Apple and Microsoft systems have been supporting this on their native toolchains since the mid-90's.
Make you can use qmake as a prebuild step and include the generated moc files in your build? I wonder how many qt headers are in the generated source files.
I think what is new is that in the mid 90s you didn't have an open source, memory safe, ergonomic, strongly typed, type inferenced language that targets multiple platforms with ease, with a decent standard lib. Rust is delivering that. Golang is delivering that. I think those two are novel in that sense.
From where I'm sitting the last few decades have been ruled by VMs and the explosion of scripting languages, because no one wanted to use those Apple/Microsoft toolchains that have been around in the 90s. While those toolchains rested on their laurels (or didn't, can't tell the difference now), Java became the enterprise workhorse.
Many devs do actually enjoy those Apple/Microsoft toolchains.
Java was marketed pretty closely to that.
[EDIT] - I didn't address your question about go.rice -- from what I know, it doesn't have this kind of thing built in, and I don't know that it even should... "flipping a production switch" is a pretty application-specific endeavor. Also this sounds like something you should be doing with your build tools..., can't include something in the binary at runtime. Maybe I misunderstood what you were asking.
To clarify, the description for go.rice is:
> go.rice is a Go package that makes working with resources such as html,js,css,images,templates, etc very easy. During development go.rice will load required files directly from disk. Upon deployment it is easy to add all resource files to a executable using the rice tool, without changing the source code for your package. go.rice provides several methods to add resources to a binary.
My question is really geared towards this pain point: the React/JS stuff can be quickly rebuilt for almost instant feedback. But even for a simple app like this example the Rust compilation takes a couple seconds on my system. You have to pay that cost even if you're just updating the JS because it has to be built into the binary. It would be nice if you're not changing the actual Rust code to be able to easily reload your JS without compiling.
Oh I think you absolutely can have that kind of flow -- go.rice DOES support that. Also, I still don't really understand because this problem seems to be easily solved by just changing your build script, or detecting environment at runtime. You could even check for the data, and if it's not present, fall back to disk.
I don't know a library that does it off the top of my head for rust though, since I'm not that familiar with rust dev.
Build an interface for the go.rice (or go-binddata/etc) such that, depending on the environment, it either pulls the file from disk or from memory. Super easy.
I seem to recall seeing a Go library that actually has this functionality built in, but I've got no idea which it was.
I'm thinking something a little fancier than include_str! because I want to include a whole subdir of resources, and I probably want to embed the gzipped version (and uncompress into RAM for when there's no "Accept-Encoding: gzip") rather than the reverse.
But yes, it is just like including files in your classpath (and making sure they end up in the jar), then serving them from a Netty endpoint or something.
It is only a matter of buying one of the commercial JDKs, or if doing GPL stuff use the open source license from ExcelsiorJET.
Those not willing to pay and already on Java 9/10, running on Linux x64, can play with the initial AOT support.
A JAR is meant to run on the JVM. There is no such thing as a "statically linked jar". The process you're referring to is more like compiling bytecode to assembly, you're converting a JAR, a thing meant to run on the JVM, to native machine code (with assembly as the step in between).
> it's only a matter of ...
Yeah, it sounds simple in theory, but somehow I don't find many projects these days that use these commercial JDKs to generate VM free assembly. In fact, I don't even know one big tech company that does so -- maybe you could enlighten me.
> Those not willing to pay and already on Java 9/10, running on Linux x64, can play with the initial AOT support.
So just about the newest version of Java just got initial support? Cool. Well this brand new community-led thoroughly open-source language has this as a core tenet, and supports compiling to many platforms very easily.
Kudos to Java for getting better, embracing a more open development methodology (I think this has been the case since 8), listening to the community more about which features to include, but when compared to projects that took a fresh look at all these concepts, and started with the open community-based approach, Java doesn't compare (except in terms of speed, JVM is pretty heckin' fast).
Ah, and if you happen to own an Android phone running version 6.0 or newer.
The free beer version of Java never supported AOT because Sun was religiously against it.
The community never managed to gain enough mindshare to keep gcj going, which was used by Red-Hat to ship native compiled versions of Eclipse, Tomcat and JBoss.
Since Oracle thankfully has another opinion on AOT, they have a long term plan to bootstrap Java and remove C++ out of the equation.
Also, Android went from Dalvik to ART right? Those are both still VMs? Latest android looks like ART + JIT, but you can't AOT a JIT (that's the whole point of doing it Just In Time)?
Maybe I should take a look at Java 9/10, but if an employer isn't requiring it, and library support is somewhere near similar, I'm definitely considering doing the project in Rust first, then Clojure, then Frege, then Java 9/10.
Outside of the insane wealth of libraries that exist as a result of no one really having a good cross-platform choice for the last few decades, I don't think I'd choose plain Java for a project today. The JVM, maybe, but not plain Java on top of it. Luckily, I'm not the only developer out there, since there are tons of people who love java are still supporting it and using it, making cool things with it, and pushing it to be better.
Until version 5.0, there was only Dalvik, a register based VM with a very basic JIT compiler.
On version 4.4, ART was introduced, but you had to explicitly enable it and many OEMs did not had it available anyway.
ART was a pure AOT compiler, at installation time on-device.
Given that it was taken hours to recompile everything when updates came on phones with lots of apps, Android 7 introduced a multi-mode interpreter/JIT/AOT toolchain.
On 7 and later, when an application starts for the first time, the interpreter written in hand optimized Assembly is executed, then control is given to the JIT, which in turn makes use of PGO.
A background AOT compiler takes the PGO data generated by the JIT and creates an optimized AOT binary for the application.
The next time an application is executed, the AOT compiled binary is used, until there is some kind of change, like an update or unexpected execution path, that requires a recompilation to take place.
http://openjdk.java.net/jeps/295
Basically Java AOT is half-assed solution like so many other Java solutions e.g Java GUIs, Java build tools, Java generics etc etc.
Either one replaces the engines in mid-flight, or parks the plane with perfect thought out solution.
Dalvik was a JIT VM. Then, for Android 5.0 (Lollipop), Android moved to AOT compile code (On installation and ROM upgrade, which is why if you ever updated Android then, you'd be sitting and waiting for a few minutes while Android optimized apps).
Then recently (I don't remember if it was for Marshmallow or Nougat) Android went back to a JIT VM on install, followed by a background AOT compile. This way installation goes faster (it doesn't have to compile everything right away), ROM upgrades go way faster (you don't have to AOT compile tens to hundreds of apps before being able to use your phone), and Android can do guided optimization during AOT (it knows which hot-paths were taken).
Sound exactly like the kind of environments were all kinds of horrible crap are used. Doubly so with the mention of IBM.
I just mentioned those, because they have Java code in production, with soft-real time deadlines for weapon targeting systems of a few milliseconds.
Usually the kind of stuff that gets mentioned that GC enabled languages aren't capable of.
It is all a matter of budget and the army has lots of it, which incidently is what allowed boring stuff like the Internet to exist.
Sure, I don't have a beef with either (although someone could go non-JVM to get either AOT and/or real-time guarantees in a better form perhaps).
But I don't think "the X and Y army uses it" serves as proof that a technology is mature.
It's not like the army doesn't have all kinds of non-critical applications, and all kinds of legacy crap and modern crap apps lying around, doing some thing or another.
It's like saying "Facebook uses our app X" as proof of maturity, when the use could be in some horrible experimental project, that Facebook tried and semi-abandoned, or is the product of some engineers "20% time" stuff...
French radar system for ballistic missile tracking and measurement.
http://www.militaryaerospace.com/articles/2009/03/thales-cho...
Aegis Weapon naval defence system, deployed across US Navy cruisers
http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aoni...
USS Bunker Hill ballistic missile defence system weapons control
http://www.militaryaerospace.com/articles/2010/04/aonix-perc...
Thanks for mentioning our product, but I have to make a few corrections:
First, the Excelsior JET Runtime license is sadly not GPL-compatible. Also, you cannot use it to target embedded systems, unless you buy Excelsior JET Embedded and pay royalties, though we are currently weighing the option to switch to OpenJDK to eliminate the latter.
Second, the Standard Edition is free even for commercial use (the above limitations apply).
Finally, other editions are available at no cost for use in public non-commercial projects. It does not matter whether the (software part of the) project is open source or not.
See https://www.excelsiorjet.com/free for details.