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.
Thanks @mands for you reply!
I am glad you did post it and really thanks for it. However, I echo your thoughts too - I was expecting a constructive engagement re FFM & io-uring, etc. but unfortunately the entire thread digressed into AI & vibe coding etc.
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.
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.
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
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)
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.
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!
reply