mands

Agreed - you don't get great JVM takes on HN, it's out of fashion here.

Our work uses modern Java (26 w/ preview features - mainly for StructuredConcurrency), and it's fantastic. Do not regret it one bit, and that's coming from using both Haskell and Python at previous companies.

Java has sum types - they are fairly recent, called sealed records, and can be exhaustively pattern matched on.

(I do agree however, Java is a great target for LLMs)

Helidon SE (https://helidon.io/#se) or Javalin (https://javalin.io/) would be more in that vein - straight-forward modern Java, super fast.

Yep, I find it easier to think of a Spring (or any DI) Bean like a parameterized module that is applied at runtime, the code within each bean is pretty procedural.

Yep, I'm using JBoss as a catch-all for older "big-iron" style Application Servers - modern Jakarta EE (10 onwards) is much more slimmed down, and a solid option.

unsure re Maven, 4.0.0 has been around the corner for years, but I think there is space for a modern alternative that is JPMS first, supports semantic versioning (i.e. tilde/carat notation) with lockfiles, and doesn't require a bunch of plugins out of the box for common use-cases. Maybe Mill (https://mill-build.org) - i've yet to try it.

It's getting better, it doesn't all have to be Spring Boot and JBoss.

There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (https://tamboui.dev/) for terminal UIs, and more.

Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resource improvements.

It's not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go / Rust did right).

I've seen this concept a few times recently and am interested.

However, what's the benefit over just using the "Claude Code for Web" feature built into the Claude Code mobile app?

It clones your repo into a VM which has a bunch of dev tools installed, you can install additional packages, set env vars, and then prompt it remotely. The sessions can be continued from the web and desktop apps, and it can even be "teleported" into the terminal app when back at a laptop/desktop.

Would be great to understand what the differences / advantages of OP approach are.

Yep, have seen this myself as previously a manager and now with a young family.

I can make incredible progress on side-projects that I never would have started with only 2-4 hours carved out over the course of a week.

There is a hopefully a Jevon's paradox here that we will have a bloom of side-projects, "what-if" / "if only I had the time" type projects come to fruition.

I recently found out about https://micro.blog/ which I think is in a similar vein (https://micro.blog/about/indieweb), but as a hosted service.

I’m not convinced that “single binary” really matters in practice. What actually matters is how easy it is to install, run, and update an application, and that depends entirely on the target user.

For end-user apps, this is basically solved: use jpackage to ship an installable app with a bundled, trimmed JRE. Better yet, distribute via the OS app store so updates are handled for you (on Linux, Flatpak is probably the right answer today).

For CLI tools, you’re already assuming a more technical audience. At that point you have two real options:

- ship everything bundled (Go/Rust static binaries, pyinstaller, jpackage)

- ship just the app and rely on a smart launcher/runtime manager (npx, bunx, uvx, jbang), and assume your technical audience can install that first

The real question isn’t "is it a single binary?", it’s "how do users install, run, and update it?". In practice, that’s already been solved by developer package managers like brew and scoop. All the Go and Rust CLIs on my machine are installed via brew, not manually downloaded from GitHub releases.

You also want CLIs on PATH or inside a dev environment (mise, direnv, etc.), so whether that executable is a true single binary or a symlink to a bundle is mostly irrelevant.

So the trade-off becomes, do you support `brew install foo-java-tool` with a bundled JRE, or do you ask users to `brew install jbang` and then `jbang install foo-tool`? Either way, the end result is the same, you run `foo-tool`.

Note, Claude Code for instance supports both options (curl | bash, brew cask, and npm -i), isn't a single binary, and that still hasn't stopped it from being the most popular CLI tool released this/last year.

There’s definitely room for improvement in Java’s packaging story, I just think the focus shouldn’t be on "single binary" as the primary goal.

Hi @rohanray - original submitter.

Apologies for submitting before the project was perhaps ready for a wider audience. I'm a boring Spring developer these days but enjoy reading about wider JVM developments and thought this was cool and worth sharing.

I think it's a shame that the HN audience's AI debates tend to derail more interesting technical conversations.

From my perspective, there are many valid reasons to use AI to bring a project to fruition, including speed, project scope, time constraints, etc. If AI helps bring to life projects that would otherwise remain daydreams, especially open-source ones, that's a win imo.

It's also far-fetched to assume someone clearly an engineer, building a project of such scope, working with low-level Java, integrating io_uring, and generating tests to ensure contracts, is a "vibe-coder" in the pejorative sense. It's unfortunate that some HN users resort to name-calling and gatekeeping, and I think some newer community rules and guidelines for AI-enhanced submissions would be helpful.

Anyway, keep coding and releasing!

We've just moved to GraphQL after using REST and bog-standard RPC, and it's been a breath of fresh air. I was considering building my own HTTP RPC system, similar to json-rpc or open-rpc, but I would have ended up with a poorly-specified GraphQL clone.

I think GraphQL's biggest issue is a naming and positioning problem. I, along with colleagues, thought for a long time that it was tied to graphs, DB query languages, and heavy backend implementations.

It's actually a typed RPC system designed for Client UIs, including SPAs and mobile. We're using it with a monolith in a code-first manner, where the schema and client code are auto-generated from backend types.

I think the project could benefit from a `graphql-lite` / `graphql-full` split, where `-lite` includes a well-documented, leaner core featureset (RPC, simple resolvers), and full mode includes federation.

Really cool, excited to see how the rest of the library pans out.

@dang perhaps auto-flagged as was top of front-page for a few minutes then disappeared, shame as a fun read.

Nice read up of the new FFM API.

Recently saw a new FFM-based zero-copy transport and RPC framework using io_uring at https://www.mvp.express/

An interesting time to be in the Java/JVM ecosystem, meanwhile, back to my Spring Boot app...tho least we're on Java 25

It's more an fun educational overview of the new FFM API.

I can't think of many actual use-cases where you'd want to use the LLVM JIT over those built-in to HotSpot.

Interfacing with existing LLVM-based systems, writing a very tight inner loop using LLVM where you absolutely need LLVM-like performance, or creating a compiler that targets LLVM using Java would be the main "real-world" use-cases.

Great read, both in terms of content, but also the approach to diagnosing the issue and debugging in general.

Modern Java (21+), Spring Boot backend, and Vaadin Hilla (https://vaadin.com/hilla) frontend is a great startup combo

I've found you can get pretty far with a couple of fixed nodes and scaling vertically before bringing in k8s these days.

Right now I'm running,

- podman, with quadlet to orchestrate both single containers and `pods` using their k8s-compatible yaml definition

- systemd for other services - you can control and harden services via systemd pretty well (see https://news.ycombinator.com/item?id=44937550 from the other day). I prefer using systemd directly for Java services over containers, seems to work better imo

- Pyinfra (https://pyinfra.com/) to manage and provision the VMs and services

- Fedora CoreOS as an immutable base OS with regular automatic updates

All seems to be working really well.

check JSpecify (https://jspecify.dev) - it's the standardised null annotation package for Java. Intellij understands the annotations so you generally get decent null-checking across your codebase.

Even better, apply at the package level via `package-info.java` (unfortunately sub-packages need to be individually marked as well)

  @NullMarked
  package com.foo;

  import org.jspecify.annotations.NullMarked;

Yes - best decision we made.

Running a new startup now and choose modern Java (JDK 21+) with Spring Boot and it's been fantastic. Have previously built startups using both Haskell and Python/Django in the past. Ignore the folks talking about it not being cool, heavy, boring or whatever - modern Java is just super nice and quick to work with.

Some positives we noted,

- "good-enough" integrated type system & language features, e.g. immutable records, type inference, generics, sum and product types with exhaustive pattern matching, lambdas, streams (along with the new stream-gatherers). We feel the gain isn't enough to switch to Kotlin anymore.

- Fantastic tooling, from IDEs, build systems, cloud integrations, remote debugging, settings configuration etc.

- Massive ecosystem - there are libraries for everything, and all major vendors, including cloud providers and most startups, have a Java SDK

- Spring Boot is a great framework, especially for API backends coming from Django - setting up things likes OAuth and OIDC was super easy. Spring AI is developing rapidly, for instance it got MCP support within a week or two of it being released

- Verbosity can be tamed with annotations processors, and Lombok if you desire (we do but understand some don't like it). JSpecify helps with null-checking.

- Performance is great, you just don't have to think about it at a startup scale, and Loom / Virtual Threads makes it even easier to build performant web services without the mental overhead of building `async` systems

I could go on, and like all things there are of course negatives, but we took the plunge and have been really happy with it.

Technical Editor: Brian Goetz - you have my attention...

Cool to see this here, using Litestar for a new project having selected and used Django/DRF company-wide in the past. I find it provides a modern "batteries-included" stack for Python, not quite as comprehensive as Django, but also not as minimal as Flask or FastAPI. For me, the advantages over Django include typing, async-first, websocket-support, along with integrations with existing projects (including Pydantic, SQLAlchemy, Jinja, OpenAPI). The higher bus-factor and release cadence was also a factor in choosing it over FastAPI.

Currently using with the following,

- [SAQ](https://saq-py.readthedocs.io/en/latest/) for background workers

- [Nginx Unit](https://unit.nginx.org/) for deployment

- [Orval](https://orval.dev/) to generate FE definitions based on the API spec.

For non-API/SPA use-cases, there are Jinja and HTMX integrations. The docs (https://docs.litestar.dev/latest/) are solid - not quite Django-tier but that's the gold standard, however the reference example is too complex imo (https://github.com/litestar-org/litestar-fullstack).

https://github.com/litestar-org/awesome-litestar has a list of useful extensions - highly recommend trying it out if you are starting a new Python web project.

Have been a big Django user over the past 10 years at my startups, but we decided to do all new projects in Litestar going forwards - typing, async, and a better REST API story made it the preferred choice for us.

+1 for django-configurations, it's been invaluable for us in helping to keep settings managable as we build / test / deploy across multiple environments and modes

For Django users, see https://www.django-unicorn.com/ - which is pretty much a port of LiveWire.

Yes, Blazor server-side is similar to LiveView, there is also LiveWire for the Laravel / PHP community (from the alpine.js creator) and Django Unicorn for the Django / Python side.

Unsure on the Rails / Ruby side, maybe stimulus-reflex, but there is also Hotwire as well ofc.

There is also Django Unicorn (https://www.django-unicorn.com/docs/), which is an implementation of LiveView for Django.

Firefox has had HW-accelerated video playback under Wayland for a few months now. Along with per-monitor mixed-/high-dpi support it is by far the best browser on Linux atm.

How is Julia in this regard?

Yes, we're using them both together in production and they complement each other really well