Pump Up is my third startup as a technical cofounder.
\nI did my PhD using Haskell to build high performance numerical compilers, so at my first startup, NStack, a cloud-based DSL for describing data processing pipelines, Haskell felt like a natural fit. It’s great for building languages, and would help us to ensure program correctness and catch more bugs at compile time. Whilst true, turns out those aren’t the things that really matter at an early stage startup.
\nFrom there, we built Datapane, a data science reporting product, in Python - due to the strength of the Python data ecosystem. However, outside of the data stack, things were not as rosy, it felt like the other extreme from Haskell.
\nThird time’s a charm - for Pump Up, built in the AI era, and with AI and agents at its core, we wanted to find a better trade-off.
\nOur first Pump Up prototypes were actually in Python, first with Django then Litestar, for the same reason every AI startup reaches for Python: that’s where the ecosystem is. We’d used Django at Datapane for 5+ years and knew the Python pitfalls well: a bolted-on and inconsistently applied type system, a split sync / async ecosystem, and performance poor enough that we were thinking hard about scaling and infrastructure far earlier than any startup should have to. Python trades speed of execution for speed of delivery, but it’s a nonlinear trade, and these days there are stacks that give you both.
\nThe pull was back to a typed, compiled language. Not all the way back to Haskell though: it gave NStack a beautiful internal streaming data model, but also type-level puzzles and lost afternoons trying to unpack and rewind the order of our monad transformer stack just so we could print a value. Ecosystem concerns abounded, it was no fun having to build our own integrations to Google Cloud when we should have been shipping. Similarly, Python’s dynamic nature is genuinely useful in a startup, where everything is malleable and half your code is a week from being rewritten.
\nCould we have good performance, a great ecosystem, stronger type-checking, flexibility - the Goldilocks of stacks? We chose Java, and that often gets a double-take, but it’s been the best choice thus far.
\nI last used Java (1.6) when working in finance in the mid-2000s, Apache Struts and JBoss application servers were all the rage. It was pretty painful: XML everywhere, deep inheritance chains, setters/getters, inner classes instead of lambdas, and so on. I’d spend the evenings learning Scheme to unwind.
\nOver the past 10 years Java has become a modern language. There has been a move away from mutable object-orientated programming to immutable data-orientated programming. Project Loom (aka virtual threads) and structured concurrency have made threads both cheap and usable. There are now real sum types and pattern matching, via sealed interfaces and exhaustive switch expressions, paving a way to functional programming, closer to a pragmatic OCaml than pure Haskell. Yet still the deep ecosystem and great tooling remain.
\nAt Pump Up we now run Java 26 and Spring Boot 4 in production. The backend is a substantial modular monolith written in a functional style. We spawn a virtual thread per agent run, scaling up to millions, each with their own state and lifecycle and written in a top-down blocking style, no async/await calls needed. They are so cheap that we can keep the agents around, simply waiting until an event wakes them.
\nA prime example of this new data-orientated functional style can be seen in our event log: a sealed interface over all the events that our agent works with, from “request an approval” to “timeout”. Everything that touches an event routes through pattern matches like this:
\nreturn switch (payload) {\n case Payload.Note _, Payload.Assignment _ -> recordSimple(payload);\n case Payload.ExceptionRaised _, Payload.Timeout _ when transitionsTo == null ->\n recordSimple(payload);\n case Payload.Action _, Payload.ExceptionRaised _, Payload.Timeout _ ->\n recordAndApply(payload, transitionsTo);\n case Payload.ApprovalRequested _, Payload.ElicitationRequested _ ->\n throw new IllegalArgumentException("Requests go through openRequest");\n // ...and so on for the remaining arms\n};\nAll possible event states are handled; miss one, or add a new one, and the codebase stops compiling. In Java 27, the compiler will suggest the missing patterns, just like Haskell, taking into account deep structural nesting.
\nThe biggest issues were verbosity and baggage, for instance: a file per class, setter/getter ceremony, access-modifiers, a lack of qualified imports. Java is almost as old as Python, and best practices have changed a lot in that time. Some of the issues were just rustiness on our part (pun not intended!), and a few months in we briefly discussed switching to Kotlin. We ultimately decided against it, as we don’t love how far Kotlin diverges from the direction of the JVM itself (e.g. virtual threads aren’t first-class there), and modern Java keeps closing the gap on its own, with improvements such as module imports and simple source files.
\nimport module java.base;\n\nvoid main() {\n IO.println("Hello, World!");\n}\nWe also run a tight Lombok configuration, with an allow-list of a handful of annotations that mainly help with Spring, since records have replaced much else of what it helped with. It’s a bit ugly but fine - I think there’s a smaller, neater language hiding inside modern Java, unburdened by the past, similar to how CoffeeScript pre-processed to JavaScript; someone should build it, maybe us, one day1.
\nThe verbosity also matters less and less these days due to AI assistants. The move to coding agents wasn’t a problem, they turn out to be very good at Java. The ecosystem is enormous, so there is plentiful training data. There’s usually one obvious way to do things, which suits a model for the same reason it suits a new hire. Slightly verbose beats cryptic: an agent can read and extend plain Java in the way that perhaps it couldn’t with some of our Haskell Lenses and Singletons type-level usage. And the feedback loops are strong: types, along with static analysers like ErrorProne and NullAway, give an agent a compile-time check on every change it makes, and JFR and the JVM’s instrumentation give it a runtime one.
\nAt NStack I chose Haskell due to my own prior personal preferences, and swung to Python in response to that experience. This time we picked for the business first and have been surprised by how little we gave up and what we gained in return. The choice still raises the odd eyebrow in SF, since the mental model many folks have of Java dates from the FactoryFactory era. But the engineers in the know tend to be exactly the pragmatists we want to hire, which is partly why I’m writing this, along with wanting to update perceptions.
There is a growing middle ground of languages that score highly on the metrics I think many startups care about - speed of writing, flexibility, performance, runtime instrumentation and debugging. C# and Go are in this bucket too, and we considered both: C#’s server-side ecosystem isn’t as deep, and Go would mean giving up sum types and exceptions for a weaker error handling story, which we weren’t willing to do. We chose “modern Java”, and are super happy with the result.
\nThere’s plenty more to write about here, the agent runtime in particular deserves its own post. If you’re building agents on the JVM, or just want to discuss: mg@mandeepgill.net, always happy to chat.
\nit’s often said that Java is a great language, burdened with horrible defaults, this would be a chance to fix that. ↩︎
\n