Well written. π I have a product written in Java, but the tooling around it is written in Python and Go. I find myself writing more and more Go tooling, and in the future will probably replace one of the Java HTTP modules with a Go equivalent. It's simply a better fit in terms of memory footprint and startup time. I don't have a strong preference between the two and I find both to be great languages. Having written Java for a long time, though, I will say that the excessive use of annotations feels quite off putting. It just doesn't feel natural to me to have a class or method littered with them.
hey i'm adam. i'm a software engineer who's way too into backend, distributed systems, and hunting down edge cases for fun. also i play piano by ear and math's kinda fun
Yeah, this lines up with what Iβve seen too - Java as the core, and Go slowly taking over tooling and smaller services.
The memory/startup angle is usually what pushes Go into that space, especially for CLIs or short-lived services where JVM warmup is just unnecessary overhead.
On annotations, I get what you mean. They help keep framework concerns out of business logic, but it can definitely start to feel like logic is split across code and metadata.
Curious, is the HTTP module change mainly about performance, or more about operational simplicity?
hey i'm adam. i'm a software engineer who's way too into backend, distributed systems, and hunting down edge cases for fun. also i play piano by ear and math's kinda fun
Yeah, I got an http service that does nothing but serve static SPA files. This can easily be done with Golang. One more candidate is a reverse-proxy alike service, but it's several magnitudes more complicated. In any case, I could easily see Go and Java-written services running into my product side-by-side. Why not.
hey i'm adam. i'm a software engineer who's way too into backend, distributed systems, and hunting down edge cases for fun. also i play piano by ear and math's kinda fun
Well written. π I have a product written in Java, but the tooling around it is written in Python and Go. I find myself writing more and more Go tooling, and in the future will probably replace one of the Java HTTP modules with a Go equivalent. It's simply a better fit in terms of memory footprint and startup time. I don't have a strong preference between the two and I find both to be great languages. Having written Java for a long time, though, I will say that the excessive use of annotations feels quite off putting. It just doesn't feel natural to me to have a class or method littered with them.
Yeah, this lines up with what Iβve seen too - Java as the core, and Go slowly taking over tooling and smaller services.
The memory/startup angle is usually what pushes Go into that space, especially for CLIs or short-lived services where JVM warmup is just unnecessary overhead.
On annotations, I get what you mean. They help keep framework concerns out of business logic, but it can definitely start to feel like logic is split across code and metadata.
Curious, is the HTTP module change mainly about performance, or more about operational simplicity?
Had to look up what "operational simplicity" means, but I'd say yes. Lower memory-requirements is a nice bonus as well.
lol fair enough. let me rephrase:
"I meant: fewer moving parts, easier to reason about, less time spent tuning knobs. But yeah, lower memory is never a bad thing π"
Yeah, I got an http service that does nothing but serve static SPA files. This can easily be done with Golang. One more candidate is a reverse-proxy alike service, but it's several magnitudes more complicated. In any case, I could easily see Go and Java-written services running into my product side-by-side. Why not.
Side-by-side is underrated. Nobody asks 'hammer vs screwdriver' β you just use both.