6 ms·

For server binaries they're typically being dropped into Docker containers not scp-d to servers directly, and the moment you go there you can just use jib and g

For server binaries they're typically being dropped into Docker containers not scp-d to servers directly, and the moment you go there you can just use jib and get a JVM container easily so there's no difference in logistics. For CLI tools whilst a single binary can be convenient, native-image lets you get those for JVM programs too these days. But it's not always the case that it's enough. In practice you will often hit the need for: a. Cross platform / cross builds. b. A way to easily update them for your users (that isn't "everyone mount this NFS/SMB drive") c. Ability to ship other files e.g. third party libraries written in other languages, config files, data files, readmes ... d. Possibly, avoiding virus scanners and Gatekeeper if you have users on Windows/macOS. Conveyor [1] does support distributing CLI tools (in any language) that can then be updated via apt-get, the Windows package manager or Sparkle on macOS. If your language/runtime supports cross-building then it can do it all from your developer laptop, you don't need each OS to build for. The resulting artifacts are single files (deb, msix/exe, zip) and it supports both self-signing and regular signing if you want that. It provides a few other neat features on Windows: • One click install that immediately adds new tools to every single terminal session without needing restarts. • If you want, silent background updates Chrome-style. If you don't, manually triggered updates. • For JVM apps specifically it automatically configures the Windows terminal to support ANSI escapes, Unicode and other modern features so you can use all the same stuff as on UNIX without needing to futz around with win32 or wrappers. Unfortunately the little default GUI that lets you trigger updates and add CLI tools to your path on macOS isn't officially launched yet, because it only works for JVM apps and not other types of program. But if anyone wants to try it just let me know, it's easy to activate. If you don't need any such features then yes, a single binary can be a bit more convenient than a zip. But the number of situations where it breaks down is pretty high and it's not so hard to handle multiple files. [1] https://hydraulic.software/ https://hydraulic.software/

tptacek 4y ago
I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docker, there's not much difference between a JVM app and any other kind. Your comment is super interesting, don't let me sound like I'm trying to shoot it down. I'm being deliberately terse to avoid creating receptors for language war antigens to bind to.
- mike_hearn 4y ago
  Sure. Given the choice of one file or 50, one file is clearly better all other things being equal. My feelings on this changed over time. About 10-15 years ago I thought single executable output was a critical feature for a language, because everywhere I went I saw people saying how important it was for them, how much simpler it made deployment. I figured, OK, people know what they want so that's what they should get. Then Docker came along. Docker images aren't single files, they're the polar opposite. They aren't even things you directly manipulate using the filesystem at all. Yet people loved it and it took over the world. Clearly what all those people demanding single-file executables were actually wanting in 95% of cases was simpler deployment, and they were phrasing it as single executable because that was concrete and understandable whereas simpler deployment is a very vague concept so who knows what you'd get if you asked for it. For people who are selecting Go or Rust or Graal native images primarily because of single-file output, I'd actually really appreciate a chance to ask a few questions or interview them quickly to learn more about the deployment context. Conveyor is all about deployment and it's good to understand more about how people are doing things and what could be better.

tptacek 4y ago

I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docker, there's not much difference between a JVM app and any other kind. Your comment is super interesting, don't let me sound like I'm trying to shoot it down. I'm being deliberately terse to avoid creating receptors for language war antigens to bind to.

mike_hearn 4y ago
Sure. Given the choice of one file or 50, one file is clearly better all other things being equal. My feelings on this changed over time. About 10-15 years ago I thought single executable output was a critical feature for a language, because everywhere I went I saw people saying how important it was for them, how much simpler it made deployment. I figured, OK, people know what they want so that's what they should get. Then Docker came along. Docker images aren't single files, they're the polar opposite. They aren't even things you directly manipulate using the filesystem at all. Yet people loved it and it took over the world. Clearly what all those people demanding single-file executables were actually wanting in 95% of cases was simpler deployment, and they were phrasing it as single executable because that was concrete and understandable whereas simpler deployment is a very vague concept so who knows what you'd get if you asked for it. For people who are selecting Go or Rust or Graal native images primarily because of single-file output, I'd actually really appreciate a chance to ask a few questions or interview them quickly to learn more about the deployment context. Conveyor is all about deployment and it's good to understand more about how people are doing things and what could be better.