Hacker News Reader

You live in a much more Java-centric world than I do. Your world seems similar to the one I inhabited for well over a decade (I wrote Java code professionally from 1997-2012), but with the rise of microservices, I'm seeing almost no interest in creating any new Java code. The JVM isn't going away...there's plenty of Scala and even some Clojure. But there's also a move towards newer platforms like Node and Go. And there's even been a rediscovery of platforms like Ruby and Python when the performance penalty doesn't come into play.

Docker enables everything to play nicely together. Capsule seems to double down on the old, monoculture way of developing. For people that want to do that, I'm sure your solution is an excellent product. But my own perspective, which may be skewed by being in the bay area, is that those people are the minority, not the majority.

> there's plenty of Scala and even some Clojure. But there's also a move towards newer platforms like Node and Go. And there's even been a rediscovery of platforms like Ruby and Python when the performance penalty doesn't come into play.

I won't say what you're saying isn't real, but it is happening on a completely different scale than the size of the Java ecosystem. Even on the JVM, what you see as "plenty of Scala" doesn't even amount to 5% -- not that it matters, but it's just an example of why I think your view is skewed.

The size of the Go ecosystem is hardly 1% of that of the JVM (rough estimate), and while Node.js/Python are "a thing" (and are the only languages/platforms of those you mentioned that are used to a substantial amount outside of startups), they are still tiny compared to the use of the JVM. Even in Silicon Valley (which is in itself a very small portion of the software world), the large "webby" application companies (with the notable exception of Facebook) are JVM shops: Amazon, Google, eBay, Twitter, Netflix are either entirely JVM or predominantly JVM, and even Facebook is making growing use of the Java.

Most of the shifts you're seeing is among non-JVM technologies. It's mostly Pythonists that switch to Go and Rubyists that switch to Elixir/Node.js, etc.. The JVM was never the biggest player in the "fast application development" arena -- at the beginning there was VB, and then Perl, and then Python/Ruby and so forth. I see no signs that there is greater movement away from the JVM -- mostly among those who realize they're better served by the "fast dev" platforms even at the cost of performance -- than towards it -- by those realizing they need the best the industry can offer in terms of performance/monitorability/tooling even at the cost of slower development.

> I'm seeing almost no interest in creating any new Java code.

I work at a firm where we have dozens of greenfield Spring Boot projects going on.

And if we perform the stats on our public cloud, Java dominates the workload.

Even if 90% of deployments are on JVM, that's 10% of deployments that you have to somehow treat differently. Docker is designed to take away this concern, just treat everything as units that need to be deployed on boxes.

So you want 100% of your deploys to be slower and less convenient than they need be just because you need to use another tool for 10% of them (and mostly for code that wasn't even written in the organization, so those images might not even need to be maintained by the organization)? I'd understand if you'd want to do that for a 50-50 mix, but not 90-10.

Also, remember that Capsule doesn't add another build step. You need to create JARs anyway, so you might as well make them capsules. You then either have the option of adding another step of building Docker images (just because you have some other Docker containers, most of them not even built by you) or not. Capsule just saves you that extra step and still lets you isolate your app in a container if you want, while making everything faster and management+logging easier. I don't think the need/wish to use containers for isolation should dictate your packaging solution.

What makes Docker-based deploys of JVM applications slower than Capsule-based deploys? All of an organization's Docker images for JVM applications would probably be based on the same base image, so there's no waste there.

Because you still need the extra step of creating the images (and layering them carefully if you want them to share dependencies other than the JVM). To run a capsule inside a container (if you want to run it in a container), you just tell Shield to launch the capsule JAR (which is created anyway by the build). In fact, you can even embed Shield itself in the capsule.

Docker is incredibly good at caching, the assumption that Docker is slow is incorrect. The first time you build or pull an image on a machine, it might take a few to get the base images, but past that it is lightning fast, and it works the same for any language and any stack.

For most companies that operate several services, having one trusted and strong way to deploy and orchestrate is way more important than an occasional load/build time when working on a new laptop / instance.

Edit: I'm not saying Capsule isn't useful, it just doesn't make any sense to say it compares to Docker, because the use-case is quite different in reality.

> Most organizations are mostly Java

...quite a bold statement. Can you cite some sources?

Sure. Estimates are that 90% of Fortune 500 companies use Java[1], and Java dominates job offering by a wide margin[2]: "its stranglehold on modern development is unshakable." The #2 platform is, unsurprisingly .Net. If you concentrate on non-Windows platforms you see that Java easily constitutes a majority. Note that what I said is adjusted by size: fledgling companies prefer quicker development.

[1]: http://www.zipcodewilmington.com/blog/why-java-skills-matter...

[2]: http://www.infoworld.com/article/2868654/it-jobs/java-develo..., http://www.infoworld.com/article/2608294/java/employers-want...