Graal would be needed and then your binaries would be huge.
No thanks. Go is much simpler. Rust is much smaller. Java can go die in the office storage closet.
C is simpler, Python is simpler, but Go?
https://leapcell.io/blog/the-origins-and-design-philosophy-o...
Go was originally designed to make life easier for googlers and make software engineering easy. In 2025, I can attest to the fact that Go is simple. Go is easy. Whether you can accomplish what you want in Go is another story. However, Go has a very basic structure and easy flow. Complexity comes from not understanding the go philosophy.
Getting AoT compiled Java programs has been a life saver. Running java -jar main.java -foo -bar is very annoying and not friendly. It needs to be packaged so you can just run tool -foo -bar
I was amazed when I tried Graal the first time, but also had to think that this is probably what C/C++ or Rust devs just see as "normal".
No thank you.
I am not in the ecosystem anymore but it did a lot of things right.
The experience after having spent over a decade primarily doing Go, Rust and Erlang (with a smattering of TypeScript, C#, Python, Swift, C, C++ etc) was the final push over the line to leave that employer.
- "Look, I’m going to say something that might sound crazy...."
- But here’s the thing: there’s nothing stopping us...
- Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe.
- The question/answer style.
- The "It's not X, It's Y" construction.
This is all in the first sections.
I’m confused by your disregard of C# AOT. It produces binaries as small as go or rust. 1.1 MB for hello world on linux.
Our Go CLI tools are like 100MB+ and often we bundle them in containers that are in the GB+ territory. Nobody cares or at least has cared enough to tell us to minimize stuff.
Try building a GraalVM native image. Minutes gone.
I would rather shove ice picks covered in lemon juice than provide Java or Ellison anymore room in the digital ecosystem. And I’m not talking politics here wrt Ellison, just awful
Even with all this it takes me substantially less time to get go, python, or ts working as a cli. Java cli is a solution looking for a problem
That's a great way of putting it. I'm a Java developer also; I'm most comfortable with Java and, dare I say, I like Java. But Java would be far down the list of tools I'd use to make a CL program.
Java on the other hand makes it impossible to get a single distributable. There is no way to get your jar + the vm into a binary. You could use graal native image, but build times are super slow, use too many resources, and it’s non-trivial to get working.
Build tooling in the Java ecosystem just isn’t good enough.
It does all of this work for you and its a standard tool that dumps out a platform specific application bundle.
The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.
Python packaging has always been painful and it’s a popular option for CLI regardless.
I don’t think there only rational explanations, technology choices are a lot about culture and dogmas too.
The rounding error there is Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.
That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.
> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.
Why do you think is this?
Forgive me if in 2026 I get triggered at the mere mention of the phrase "java build".
Lots of us had long relationships with Java, relationships marked by toxicity and abuse. We moved on. Now Java says it is changed, it has matured. Well, it could be true, probably it is even true, but on the other hand, now your toxic ex found out his father, and his name is Larry Ellison.
And GraalVM compiled Java is more than speedy.
Back in, say, 2005, two decades ago, on computers from back then, sure, the java startup time from the CLI were noticeable. But on today's computers?
Nowadays when it comes to terminal apps I wrote both Clojure (Babashka), Bash and Java (recently I needed something from a .jar and had no convenient Clojure wrapper and didn't want to bother, so I just wrote my CLI app in Java).
Maybe, maybe, maybe that I do feel the startup time when I run my CLI Java app on Raspberry Pis. Raspberry Pi 2 and 3s that is (for I don't have any newer).
Startup times aren't an issue. But there may be other reasons to prefer other languages to write CLI apps.
Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.
https://github.com/WilliamAGH/tui4j
It combines a port of BubbleTea from Go, and Textual and other inspired rewrites of other functionality.
It’s a fork of someone’s earlier work that I sought to expand/stabilize.
I built a beautifully simple LLM chat interface with full dialog windows, animations, and full support for keyboard and mouse interactivity parity, showing what this Java library is capable of.
Example chat app: https://github.com/WilliamAGH/brief
Would love to see others build similar things with it!
I can’t find any editor or IDE that comes close to IntelliJ. If we want Java in the terminal, we may also need to think how to write Java in the terminal or are they orthogonal?
You have to learn ( and maintain knowledge of ) build tooling, unit test frameworks, tools for front end / back end development, distribution and packaging systems, directory structures to accommodate all those, etc. ad nauseum.
Then something new and shiny comes out, with much smaller tooling. The lure of easy software construction seduces the user.
It never ends.
based2•1h ago
https://www.jbang.dev/