Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

21–30 of 191 posts

Re: 2026: The Year of Java in the Terminal?

#21
post #11

Maybe some of the old beliefs regarding startup time etc are no longer valid. Maybe the programming model isn’t as verbose as it used to be. But I don’t want to distribute a 200MB+ binary. I have colleagues who tell me that c# scripting is so awesome. One only needs .NET installed or use AOT or whatever. Sorry but Go and Rust and good forgive a python script is smaller and mostly easier to read and write then most st…

Using modules and jlink your Java image would be much smaller than 200mb. Full desktop apps with ui’s can get down to 30mb.

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.

Re: 2026: The Year of Java in the Terminal?

#22
Babashka has been available and has had a growing following since 2019. I have many babashka shebang deployed scripts with fast startup. While I would never desire to use Java syntax, AOT capable JVM based Clojure libraries are available and can be loaded dynamically. Built via graal. https://babashka.org

Re: 2026: The Year of Java in the Terminal?

#23

I've been a Java developer for twenty years. I've used it for everything front front end to distributed systems. I've built gradle plug-ins and clips with JAVA. I have every shortcut in intellij memorized. 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

> 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.

Re: 2026: The Year of Java in the Terminal?

#25
There are approximately no use cases that would get me to run a CLI written in Java on my machine, especially if it required having a JVM installed. There's just no reason for it.

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.

Re: 2026: The Year of Java in the Terminal?

#26
post #18

Java will never become a player in CLI tooling until build packaging becomes first class. Go, Rust, and other languages are so common because their build tooling is dead simple. You can easily get a single file distributable in a single command. go build, cargo build, dotnet publish —-self-contained. Java on the other hand makes it impossible to get a single distributable. There is no way to get your jar + the vm int…

Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”

Re: 2026: The Year of Java in the Terminal?

#27
post #17

The moment you introduce the jvm, is the moment people flee. 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.

Go and "simpler"? Really? C is simpler, Python is simpler, but Go?

Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.

Re: 2026: The Year of Java in the Terminal?

#28
post #17

The moment you introduce the jvm, is the moment people flee. 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.

Go and "simpler"? Really? C is simpler, Python is simpler, but Go?

Indeed

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.

Re: 2026: The Year of Java in the Terminal?

#29
Well, the year is 2003 and I am on a hot dungeon with bad Air Conditioning, figuring out the correct spells for a black magic ant build. A few years later I am writing tons of XML, first for vanilla J2EE, then for spring. We complained, we wondered, nobody cared until one day we decided "fuck that shit, I don't care if ruby is slow as molasses, I just want the pain to go away!"

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.

Re: 2026: The Year of Java in the Terminal?

#30
post #9

Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful. No thank you.

When did you last program Java? It’s changed a lot from the Java 8 days. I am not in the ecosystem anymore but it did a lot of things right.

I concur with Nick, and the last time I programmed Java professionally was late 2024, with all of the latest and greatest frameworks (obviously not my choice) and tooling (which, to be fair to the Java ecosystem, is second to none).

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.

Post reply on HN