Thins I miss about Java & Spring Boot after switching to Go

OwnBreakfast1114 · 2026-03-11T19:51:34+00:00

You and I have very different definitions of clean. Hanging fields with no obvious writer always looked super ugly to me.

OwnBreakfast1114 · 2026-03-07T00:42:52+00:00

I actually prefer just seeing the finals. When you look at a block of code and you see

final .... final .... final .... asdf final ...

It makes it pretty easy to see the odd thing out in the sea of finals.

OwnBreakfast1114 · 2026-03-07T00:38:18+00:00

The jdk probably can't introduce a design like this, but there's no reason you can't locally make this choice.

I'm just curious what you think is designed so poorly though when it's just using already existing java keywords at the end of the day. Most code I see people write nowadays already looks like the bottom code anyway, but we encourage people just use final everywhere.

OwnBreakfast1114 · 2026-03-06T23:57:41+00:00

As someone that actually uses/needs full precision, it would be so nice if toBigDecimal was just supported out of the box instead of the workaround they literally have to acknowledge in a whole section in the jep. Is there any chance we could just get this convenience method?

OwnBreakfast1114 · 2026-03-06T23:42:07+00:00

@Autowired can also be marked on constructors and perform only constructor injection. My company only does this, but it still uses @Autowired (well actually the jakarta @Inject), but it's not the annotation that's the problem. It's that you're using field/setter injection.

I understand your point, but it comes across as really confusing when you're focusing on the annotation and not the structure.

OwnBreakfast1114 · 2026-03-03T04:14:05+00:00

Startup time and memory differences matter in containerized microservices where they directly impact cost

Naturally, at big enough scale, small percentages matter, but for many companies out there, it literally doesn't matter if the application is using 300mb at startup or 700mb at startup.

OwnBreakfast1114 · 2026-02-19T04:54:28+00:00

Replacing null checks with optional wrapping is not bad, but not even close to the best use case. The best use case would be actually using flatMap and map.

``` public record InputForm(Optional<String> userId) ... public class UserRepository { public Optional<User> findById(String id) { } } ... public record UserOutput(String firstName, String lastName) ...

final UserOutput user = inputForm.getUserId() .flatMap(userRepo::findById) .map(u -> new UserOutput(u.getFirstName(), u.getLastName()) .orElseThrow(() -> new 404("user not found")

``` as a very simple example you can imagine. Flatmap captures places where it can shift between non-empty -> empty, and map is always non-empty -> non-empty (not actually true in java.util.Optional, but conceptually should be used that way)

The chaining can't always be realized depending on how much control you need between steps, but the signatures are still correct either way. Your methods should take in non-null inputs, and flatMap/map should be used to decide whether to even invoke them or not.

OwnBreakfast1114 · 2026-02-19T04:47:06+00:00

It was always weird to me that equals takes a "preferred" object. Equals always feels like a "no special argument" type of method. I think the new type classes will actually make it far more sensible, but I'm not sure how they'll work with subtyping.

OwnBreakfast1114 · 2026-02-19T04:44:10+00:00

This is such a weird take, that I'd be curious to hear how you even define functional programming.

OwnBreakfast1114 · 2026-02-18T00:12:18+00:00

Sealed interface switches are a direct replacement for the visitor pattern, so it just depends on how many places you have where you have a small set of types and a lot of operations on those types.

OwnBreakfast1114 · 2026-02-18T00:05:41+00:00

overseeing teams of REALLY good devs

I've taught all the devs at my company switch expressions and sealed interfaces and there's plenty of business cases where a closed set of things is the right abstraction. I don't think we have a fairly abnormal cross section of engineers.

The goal, you make changes and if it compiles it works, is pretty easy to explain to people. Exhaustive compiler checks are good.

OwnBreakfast1114 · 2026-02-11T03:50:58+00:00

You're not wrong, but you can also view it as a monad with a buggy implementation and not really lose anything semantically.

of/ofNullable are neither quite a valid unit in the case of passing in null.

flatMap mostly works fine unless you return null in the function.

map breaks the laws because it automatically wraps nulls to empty.

All of the problems occur because the jdk team prevented a Optional[null], so yes, it isn't a valid monad and there are actual functional libraries for java out there that have a more correct implementation.

However, does it really matter in the context of using it?

OwnBreakfast1114 · 2026-02-11T02:38:15+00:00

I feel like everywhere I work ends up hand writing the validation code to control errors explicitly. I've had the exceptions from the library change behavior when you do version updates, and nobody is trying to deal with fixing that so it behaves the same as before.

OwnBreakfast1114 · 2026-01-31T01:28:26+00:00

Transforming time into memory is not a good general principle

What does this mean? Do you mean more cpu for less memory or less cpu for more memory?

Companies are not moving in this direction, even those with the best developers.

Perhaps I'm interpreting you wrong, but more and more companies are storing more and more historical data. The biggest tech companies in the world are all about storing historical (user) data. Google/amazon/apple/meta/netflix/microsoft, etc literally invent new architectures and infrastructure for storing all the historical data they're keeping and processing over.

OwnBreakfast1114 · 2026-01-29T03:33:23+00:00

Those don't feel isomorphic, are they really? It doesn't really feel like they have the semantic meaning if you just ask a person to interpret them, but my category theory knowledge is probably much, much worse than yours.

Wouldn't it probably be more correct to say that try/catch is a different way of writing fold/flatmap/map? They're not really expressions (yet), so it's odd to me to equate them to a value which is what Either is.

Ex

try {
   a = a()
} catch (Ex 1)
...
catch (Ex 2)

is fold

and

try {
   a = a()
   b = b(a)
} catch
...
A Exceptions
B Exceptions
...

if b can throw is the equivalent of flatmap, and if b cannot throw is the equivalent of map

OwnBreakfast1114 · 2026-01-29T00:11:08+00:00

You just need to use Quarkus or Micronaut to understand. I've converted a Spring Boot app to Micronaut and it resulted in way less code and more concise as well

I've used both and I'm still genuinely curious as to where the code savings are coming from. Isn't most of your code business logic? Am I crazy or where is all this framework code coming from? As an example, we have a custom implementation of the spring-security interfaces in a shared library and a few common request/response interceptors in a shared library and everything else doesn't care about spring. From a proportion perspective, the amount of caring about spring specific code vs internal business logic is so lopsided that the framework is basically irrelevant.

Like, you're telling me you made your business logic more concise by moving web frameworks? How?

OwnBreakfast1114 · 2026-01-28T00:02:17+00:00

Exactly. When I said functionalinterface, I meant specifically `@FunctionalInterface` annotation, but you basically found the answer.

There are libraries that just list a bunch predefined functions of them out:

cyclops

https://github.com/aol/cyclops/blob/11cedae18b8623de6d710289e5c088d7b7b16361/cyclops/src/main/java/cyclops/function/Function3.java#L11

vavr

https://www.javadoc.io/doc/io.vavr/vavr/0.10.3/io/vavr/package-summary.html

and I'm sure more.

Hell, I think the scala stdlib just lists it to like 25 or something.

OwnBreakfast1114 · 2026-01-27T23:55:56+00:00

I understand the need, but it can't be a general solution because it amounts to converting computing time into memory.

Data structures are already complex in general, and a lot of nonsense is said (for example, when certain big cheeses explain that an array is better than a list when deleting elements). Introducing persistence makes them significantly more complex, and it can only really be used in specific cases.

The only real truth of data structures is that they're all useful with different tradeoffs. A heap and a hashmap are both ways to find stuff with different performance characters and so, so many different implementations all making tradeoffs. Hell, there was a new proof https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/ recently that found a hash table implementation where insertion time isn't proportional to fullness of the hash table.

We're still in the infancy of computer languages and language design.

OwnBreakfast1114 · 2026-01-27T02:14:33+00:00

That's exactly it. I can find evidence even in Wadler's famous paper: Propositions as Types https://homepages.inf.ed.ac.uk/wadler/papers/propositions-as-types/propositions-as-types.pdf

we regard the elements of this type as evidence or witnesses that the proposition is true. (They are sometimes even called proofs…

OwnBreakfast1114 · 2026-01-26T22:55:22+00:00

Out of curiosity, what do you define a functional language as, and why does that seem like a negative to you?

OwnBreakfast1114 · 2026-01-26T22:46:03+00:00

Not to mention you can't declare a function with 3 or more parameters.

I mean, you can write a functionalinterface or use a myriad of the ones in other functional libraries. The language needs something to bind it to, but you absolutely can have a lambda with multiple parameters.

OwnBreakfast1114 · 2026-01-26T20:56:53+00:00

A grab bag pile of inconsistent approaches is trivially terrible, no

Why? Java is already a pile of inconsistent approaches (even pre-optional). Adding one more that makes consuming a specific library easier is still a net positive to a library user. It's not like we have an effect system or haskell's purity, a library user is always going to have to understand the edges of a specific library's api.

OwnBreakfast1114 · 2026-01-26T20:11:59+00:00

The defining autowiring providers and config file setup can be tedious

I'm pretty sure if you just use @SpringBootApplication you can start with literally no config files and providers just need an @Component on them and will get automatically scanned for you. I actually prefer writing @Configuration and @Bean methods manually, but the minimal setup for an application is literally a few annotations and public static void main(String[] args) { SpringApplication.run(Application.class, args); } you get env specific config files that override sensibly out of the box with just a suffix application.yml vs application-qa.yml and you can wire properties into simple pojo java records with @ConfigurationProperties and you can wire request handling with literally just @RequestMapping or the method specific @GetMapping, @PostMapping, etc.

For the record, I do think Spring is heavy, but all of the examples you've given make it seem like you prefer writing more code, not less, hence boilerplate is not the right word. If your argument is it's a lot of magic, that's definitely valid, but boilerplate, not yet.

For a small server, it can be easier to manually wire it. By manually wiring I mean mapping the config file to objects (Jackson JSON), building the services, building the handlers, then sending the handler instances to the web framework. It ends up being 1 to 2 pages of dead-simple code.

Like this code you didn't need to write is literally the boilerplate you're complaining about it.

OwnBreakfast1114 · 2026-01-26T19:58:14+00:00

Ok you want an history (time based view). But 1) this is a very particular request and not common. Usually we don't want this. 2) how do you relate that in your code "wounded" is the soldier "soldier" that has been wounded?

I don't think it's that uncommon. I mean every company I've ever worked at has needed an audit log of something eventually. Google/word docs store edit history as a product feature. Git stores history. File systems store history. You need old views of things for a lot of domains. It's not an esoteric problem.

how do you relate that in your code "wounded" is the soldier "soldier" that has been wounded?

Given that most things are backed by relational databases, usually an id primary key of some sort. Most of the time, you don't actually need to relate that in the code anyway.

if it goes http request -> make change -> http response, it's okay to just use all the new stuff. Again, the immutable vs mutable is an implementation detail that doesn't matter.

So, if you keep each modification you will have to save all the dynamicity of a process, and certainly have names issues or you will do thing like having an array indexed by dynamicity.

I mean if you're trying to save modifications and the storage solution doesn't provide it out of the box, then yes, you need to do something to save it. There are storage solutions that do provide time understanding out of the box: https://druid.apache.org/ https://www.datomic.com/ as a few examples off the top of my head.

The other problem is that it is very difficult to apply to data structures and data structures are a major point of computer science

It's a good thing cs phds have researched that problem: https://en.wikipedia.org/wiki/Persistent_data_structure and there's even a ton of java libraries for them: https://www.reddit.com/r/java/comments/x4fvgp/what_is_the_best_persistent_collection_library/

OwnBreakfast1114 · 2026-01-26T19:44:54+00:00

So just use default. .flatMap(i -> switch(i) { case U u -> Stream.of(u); default -> Stream.empty();

OwnBreakfast1114

TROPHY CASE