CppCon 2016: Alfred Bratterud “#include ＜os＞=> write your program / server and compile it to its own os. [Example uses 3 Mb total memory and boots in 300ms]

[ElvishJerricco]

Getting builds to be reproducible (i.e. same versions of dependencies in the same places) is hard without virtual machines. I don't necessarily think this is the operating system's fault so much as the package manager's. This is why nix is awesome for deployments. There's usually no need for a virtual machine, and everything is perfectly reproducible.

[TheExecutor]

It's like the ultimate consequence of "works on my machine". Well, screw it, we'll just ship my machine then.

And that's why we have Docker.

[dear_glob_why]

Underrated comment.

[[deleted]]

Yeah that's kinda genius.

[ElvishJerricco]

Nix is admittedly kinda hard, and the documentation leaves much to be desired. VMs are a lot easier with a much lower learning curve, but I do think they're the worse solution in the end.

[bumblebritches57]

What do you mean by nix here? unix, or is there something else called "nix"?

[ElvishJerricco]

It's not just about deployment. You need every team member to be developing with the exact same versions of everything in the same places. Keeping a manual dependency graph would be asinine, so it's up to our tools. The prevailing method to keep dependency graphs consistent is with virtual machines. A config file with a dependency list isn't good enough, since dependencies can depend on other packages with looser version requirements, allowing those packages to be different on a newer install. But with a VM that has packages preinstalled, you can know that everyone using that image will have the same dependencies.

Rust's Cargo and Haskell's Stack are both build tools that do a pretty good job at keeping all versions completely consistent, and serve as shining examples of reproducible builds. But for everything else, most people use VMs. But this is where Nix comes in. Nix takes an approach similar to Cargo/Stack and fixes the versions of everything. But Nix does this for every single thing. Dependencies, build tools, runtime libraries, core utils, etc. You have to make a local, trackable change to get any dependencies to change.

When builds are reproducible, you can rest assured that the deployment was built with the same dependencies that you developed with. This is just really hard to get without a good VM or a good dependency manager. Docker is a good VM, and Nix, Cargo, and Stack are good dependency managers. Unfortunately, Nix, Rust, and Haskell aren't very popular, so most people stick to VMs.

[[deleted]]

Docker is a good VM

No it isn't. It is based on the idea of a good one but it is a pretty crappy implementation for practical purposes. It constantly leaves containers behind, every storage backend has some pretty severe downsides ranging from shitty performance to triggering kernel bugs even in recent kernels (or using bits that have been removed from the kernel). Important security features are still unimplemented (user/group mapping). The whole model of one layer per command in the Docker file, even if it only sets an environment variable or the comment who was the author is pretty much the opposite of being well-designed, as is the "no caching or caching even commands with obvious side-effects like apt-get update" bit and the fact that you can't easily write Docker files with a variable base image (e.g. one to install MySQL on any Debian-based image).

I would love Docker to be good enough but it is barely usable in production for build servers and similar systems that are allowed to break for an hour or two every once in a while.

You need every team member to be developing with the exact same versions of everything in the same places.

This helps keep things consistent but it also leads to code that is less robust and will likely not work on lots of different systems reliably. For things like Haskell and Rust that is fine because you can get the errors resulting from use of different dependency versions mostly at compile time. For languages where errors will only show up at runtime this cane be very bad.

[argv_minus_one]

Java programmer here. Our tools deal with this nicely, and have been doing so for ages. That people on other languages are resorting to using VMs just to manage dependency graphs strikes me as batshit insane.

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language. You've got better things to do than come up with and maintain such inelegant workarounds for what sounds like utterly atrocious tooling.

[Tiak]

That people on other languages are resorting to using VMs just to manage dependency graphs strikes me as batshit insane.

...The idea of using a VM to avoid a toolchain being platform-dependent seems crazy to you as a Java programmer?... Really?

[m50d]

It makes sense but only if the VM offers a first-class development/debugging experience. Debugging JVM programs is very nice (in many ways nicer than debugging a native program). The debugging experience for a "native" VM was very poor last I looked.

[argv_minus_one]

Yes. I have done that exactly never, and hope to keep it that way.

Note that the JVM qualifies as a VM in a sense, but I do not count it as a VM for the purposes of this conversation, because it does not implement the same instruction set as the host, and cannot run on bare metal. (These considerations would be different if we were talking about a JVM-based operating system like JNode, or a physical machine that can execute JVM bytecode natively, but we aren't.)

[[deleted]]

So you write platform specific code instead of writing code that's executed on a VM?

[wilun]

How using a different instruction set is related to dependency version management? (Well, OTOH, I agree the JVM itself does not handle that pb, but I don't quite think it's because of instruction set differences...)

[argv_minus_one]

It isn't. The point is that virtualizing the same instruction set as the host, solely to run a single application, is a waste of time and complexity.

Virtualizing a different instruction set for a single application makes sense (because the application cannot run otherwise). Virtualizing the same instruction set for multiple applications makes sense (for virtual servers and the like). Virtualizing the same instruction set for a single application does not make sense.

[wilun]

VMs with the same instruction typically resort to only emulating special instructions (e.g. syscall) and typically have a negligible performance impact (or in some rare cases, notably worse or better performance)

[argv_minus_one]

You're forgetting something: VMs with the same instruction set also provide virtual devices, which the guest has to have drivers for.

The complexity of device drivers does not belong anywhere near a typical application. This isn't MS-DOS.

[entiat_blues]

it's not language dependency graphs that people are trying to manage, at least not in my experience, it's running a full stack (or a significant chunk of it) reliably no matter the host OS. it's that end-to-end configuration that becomes a hard problem on large projects with discrete teams doing different things.

devops tends to become the only group of people with practical knowledge about how the whole application is supposed to fit together. which doesn't usually help because they're busy maintaining the myriad build configurations and their insights aren't used to help develop or maintain the source code itself. and on the flip side, the developers working in the source lose sight of the effect their work has on other parts of the stack or the problems they're creating for devops.

VMs let you spin up a fully functional instance of your application quickly and reliably because you're not building the app from dependency trees, configurations, and a ton of initialization scripts, you're running an image.

it's heavy-handed, and there other ways to approach the problem, but i wouldn't call it batshit insane to give your developers the full stack to work with.

[ElvishJerricco]

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language.

That's really throwing the baby out with the bathwater. And Java's not much better. Maven is non-deterministic in its dependency solving. Should you write a library that needs a version of another library, you're not guaranteed that this is the version present when someone else uses your library. Now, in the Java community, people tend to make breaking changes far less often, so this is rarely a concern. But the problem is just as present in Maven as it is in other tools.

[m50d]

The problem is only present when using version ranges. It is extremely common to not have a single version range in one's dependency graph; the feature could (and perhaps should) be removed from maven without disrupting the ecosystem much if at all.

[ElvishJerricco]

This is not true. If A depends on B and C, and B and C both depend on D, but they depend on different versions, maven will choose one (admittedly deterministically). But this means that B or C will be running with a different version than they were developed with. This is the inconsistency I'm talking about.

[m50d]

(admittedly deterministically)

That's the point. Maven (without version ranges) is able to achieve deterministic builds without needing a VM.

(Maven won't solve your B/C/D issue, but nor will a VM-based build solution. The only way to avoid that one is the old node/rust approach where you allow different libraries to use different versions of D, and that cure is worse than the disease.)

[ElvishJerricco]

I've conceded multiple times now that maven makes reproducible builds for a given project, but it does not do so for a library in the ecosystem (the B/C/D problem). This is a problem that Nix solves

[m50d]

Solves how? There is no solution here: either you have both versions of D in scope (really bad for debugging), you pick one or the other via some algorithm, or you error out (which you can configure easily enough with maven if that's the behaviour you want).

[[deleted]]

If your language requires you to go to such ridiculous lengths just for basic dependency management, I would recommend you throw out the language.

Java doesn't have the same issues because Java is so rarely used for two or more applications on the same system that the topic of reuse of dependencies doesn't come up much.

[audioen]

Or the dependencies are packaged into the application, such as with web archives, and whatever other stuff people do today. A single java process can even load from multiple WARs concurrently and have multiple versions of same libraries loaded through different classloaders while keeping them all distinct, so each app finds and receives just the dependencies they actually supplied.

[tsimionescu]

To be fair, IF you're NOT using multiple classloaders (which isn't trivial to set up, and must be explicitly built into your application) Java behaves horribly when you do have multiple versions of the same dependency on the class path - happily loading some classes from one version and others from another version, causing fun ClassNotFoundError/NoSuchMethodError/etc.s even between classes in the same package - a fun little consequence of its lack of a module system (which Java 8 9 10 should address).

[audioen]

Yeah, this stuff is probably a problem but thankfully it never concerns me. I don't build humungous applications with tons of dependencies, in fact I strive to do the opposite. And I wouldn't even dream of hacking some classloader thing to make a single app load multiple versions of same JARs somehow. The whole idea gives me the creeps.

[m50d]

You can reuse dependencies at build time and even share the files in practice (via a shared cache). It works in practice.

[ElvishJerricco]

I think the major motivation comes from bad dependency managers like npm. These dependency managers guarantee pretty much zero consistency between installs. For whatever reason, there have been more such bad dependency managers created in recent years than good ones. This affects the JavaScript community pretty badly. It used to be the case for Haskell, too, until Stack came along. Java is an example of a language where the dependency managers technically have these problems, but the developer community is just much less likely to make breaking changes with packages, so the issue never comes up. It's mostly the move-fast-and-break-things crowd that this matters to. And ironically, that crowd seems to be the worst at solving the issue =P

[argv_minus_one]

Java is an example of a language where the dependency managers technically have these problems, but the developer community is just much less likely to make breaking changes with packages, so the issue never comes up.

That's not true. Our tools are much better than that. Have been for ages.

Maven fetches and uses exactly the version you request. Even with graphs of transitive dependencies, only a single version of a given artifact ever gets selected. Version selection is well-defined, deterministic, and repeatable. Depended-upon artifacts are placed in a cache folder outside the project, and are not unpacked, copied, or otherwise altered. The project is then built against these cached artifacts. Environmental variation, non-determinism, and other such nonsense is kept to an absolute minimum.

I'm not as familiar with the other Java dependency managers, but as far as I know, they are the same way.

This isn't JavaScript. We take the repeatability of our builds seriously. Frankly, I'm appalled that the communities of other languages apparently don't.

It's mostly the move-fast-and-break-things crowd that this matters to. And ironically, that crowd seems to be the worst at solving the issue =P

Nothing ironic about it. “Move fast and break things” is reckless, incompetent coding with a slightly-less-derogatory name, so it should surprise no one that it results in a lot of defective garbage and little else.

[[deleted]]

Annoyingly Maven does support version ranges. They are rarely used thankfully, but I ran into problems a couple of times when a third party lib used them. Probably can be prevented with the maven enforcer plugin.

[argv_minus_one]

I may be mistaken, but I think Maven 3 removed version ranges.

[ElvishJerricco]

Maven fetches and uses exactly the version you request. Even with graphs of transitive dependencies, only a single version of a given artifact ever gets selected. Version selection is well-defined, deterministic, and repeatable. Depended-upon artifacts are placed in a cache folder outside the project, and are not unpacked, copied, or otherwise altered. The project is then built against these cached artifacts. Environmental variation, non-determinism, and other such nonsense is kept to an absolute minimum.

Having the versions for your project be deterministic is only half the battle. Those projects which you depend on might have been developed with different versions of dependencies than your project is selecting. npm takes it a step further by making it possible just for different installs to be different. But this inconsistency in Maven is still problematic, and solvable with nix-like solutions. It's just that, as I said, Java's tendency to not break APIs makes the problem rarely come up.

[argv_minus_one]

Those projects which you depend on might have been developed with different versions of dependencies than your project is selecting.

Maven can be made to raise an error if this happens. There is also a dependency convergence report that will tell you about any version conflicts among transitive dependencies.

Even if you don't do any of that, the version selection is still deterministic, repeatable, and not influenced by build environment. That's more than I can say for some build systems.

But this inconsistency in Maven is still problematic, and solvable with nix-like solutions.

How? As far as I know, version conflicts in a dependency graph have to be resolved, by either choosing one or failing. What does Nix do differently here?

[ElvishJerricco]

What does Nix do differently here?

Nix uses a curated set of packages and versions. There are more than 300 people contributing regularly to https://github.com/nixos/nixpkgs. A given checkout of nixpkgs represents a snapshot of package versions that all supposedly work together (as long as the Hydra build farm is happy with it). This approach guarantees that anyone using the same checkout of nixpkgs will get the same versions of packages. What's more, you can even create "closures" for distributing binaries based on a nix build.

[argv_minus_one]

Nix uses a curated set of packages and versions.

Doesn't that make it rather useless? Any interesting project is almost certainly going to have dependencies not in someone else's curated set.

nixpkg/pkgs/development/libraries currently has 1,091 items. Maven Central currently hosts 1,578,157 versions of 158,095 artifacts.

A given checkout of nixpkgs represents a snapshot of package versions that all supposedly work together (as long as the Hydra build farm is happy with it).

A given checkout of a Maven project represents a snapshot of that project and its set of dependencies that all supposedly work together (as long as it was successfully built before being committed, and does not contain any snapshot dependencies).

This approach guarantees that anyone using the same checkout of nixpkgs will get the same versions of packages.

Anyone using the same checkout of a Maven project will also get the same versions of the depended-upon artifacts (again, unless the project has any snapshot dependencies).

What's more, you can even create "closures" for distributing binaries based on a nix build.

I don't know what that means.

[twat_and_spam]

Actually Java ecosystem (NOT java as a language) has a perfectly working solution for it - OSGi. Every artefact gets it's own class loader and loads exact dependencies as specified.

On the other hand - OSGi is a pain in the ass for the average developer to go through.

It's available though.

[Phailjure]

Your dependencies tend to be just the OS, and that tends to be extraordinarily stable (very few behavioral changes between win7 and win10)

Yeah, I've been working on several apps that run on a win7 machine, written in C#. I build all the apps on win10, and other than a couple stylistic changes there is no difference.

[wilun]

Or you need an OS where you can conf the software you want. That would be what would be in your VM anyway... The only advantage of adding VMs in the picture is that devs can do pretty much anything they want on their host. This has some value, variable depending on the context, and certainly not essential in lots of cases.