Hacker News Reader

Comment by Frozenlock | Hacker News Reader

> Distribute a Clojure application without embedding Clojure itself in the capsule, and have Clojure downloaded the first time the capsule is launched. The Clojure runtime will be cached and shared among all Clojure capsules so it will only be downloaded once.

How would that be useful?

View on HN

Your artifacts would be smaller (the Clojure runtime is ~4MB; the Scala runtime is ~5MB) and you could even have the runtime auto-update if you like. But the main point is just to show how flexible Capsule is, and how you can have the deployment adapt itself to the environment in many ways.

I think "smaller" is not what we should be chasing. Given drive sizes and network speeds, I'd much rather have "simple and reliable" than "small". In other words, I prefer to save my time rather than my computer's time.

As for the project, I'm trying to understand what it provides over "lein uberjar" that I'm already using (and happy with it)?

1. Uberjar doesn't always work. It may cause resource collision (and even shading doesn't always work as some libraries are resistant to shading). It also doesn't support native libraries. Capsule always works and is just as easy to build as an uberjar with the lein plugin.

2. Even with an uberjar you need a platform specific startup script (to pick a JVM version, set JVM flags, set up a boot classpath if you need it or agents if you need them). With Capsule, all of that is stored as metadata in the manifest, and the capsule sets up everything on its own.

3. Capsule provides other features, such as launching itself inside a container (and it's better than Docker because the container is unprivileged, and doesn't require an image), packaging as a native application (with icons etc.), launching itself as a daemon/service and more.

I might partially agree, though point 2 went away for us with Docker.

See my other comment about Capsule Shield: https://github.com/puniverse/capsule-shield

You're from Parallel Universe? I've played with the idea of a programming language, looking for an async layer that supports Scala style Future[T]s. Possible with Quasar?

Not entirely sure what you mean by "the idea of a programming language". Scala-like futures are already in the JDK as CompletableFuture. Quasar is something different (and, I believe, better): it provides true fibers (aka lightweight threads), just like Erlang or Go.

I've meant playing with the idea for a programming language.

With Future I've meant would it be easy to put a Future based API which I like b/c of composiblity on top of Quasar, e.g. on top of fibers.

(Futures are just an API to concurrency not concurrency itself that can sit on actors, forkjoin, ...)

Then sure. But check out this talk/blog post, which explains why such monadic futures are not a good way to compose asynchronous code: http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...

Reply on news.ycombinator.com