The startup time comparisons may not seem like a big deal but having an app take several seconds just to start up can burn you really bad in incidents where you want to roll new application versions. And yes, it is possible to engineer around it but I think a better question to ask is why these apps take so goddamn long to start in the first place. There should be some kind of compile or runtime flag to speed this up.
One year after switching from Java to Go
11–20 of 503 posts
Re: One year after switching from Java to Go
#12Agree. Go is a joy to use. Java is okay but struggles with scaling unless you have the money to burn for this.
To scale up servers in Java requires spinning up highly priced servers with lots of RAM, which that is a lot of money. Using a low spec server is cheaper but you will get more JVM crashes and have to waste time doing more JVM tuning to prevent them. This is not even talking about having lots of 'microservices' to scale which that also means more money spent per month.
Using Go just reduces all of that and saves lots of money and is extremely efficient enough to rely on and it directly compiles to a single binary for deployment.
From a cost and efficiency perspective, Java is just not the answer even though it is a sound language, unlike JavaScript or TypeScript. Given a choice I'd rather use Java or even Kotlin or JS/TS. But the cost reduction, performance gains and onboarding experience with Golang is hard to beat for backend.
Would stay really far away from JavaScript or TypeScript for anything backend.
Re: One year after switching from Java to Go
#13Seems like they wrote slow memory hogging software and didn't make any attempt at optimizing it.
E.g. there's no mention of AOT compilation for Java. No hints at what actually consumed 2GB of RAM.
Greenfield projects are always more fun.
Re: One year after switching from Java to Go
#14I’ve been out of the Java scene for a really long time, but will be coming back to it soon. I’m curious - these performance issues described here, are they inherit to how Java itself? Is it baggage from Spring/Boot? Are there ways to get more bang for the buck with some careful choices in a system like this? The closest I’ve done to Java recently is C#, which I think may have similar challenges, but overall didn’t se…
You can do AOT compilation with GraalVM to reduce both startup times and memory usage, but then you don't have the JIT.
Re: One year after switching from Java to Go
#15I’ve been out of the Java scene for a really long time, but will be coming back to it soon. I’m curious - these performance issues described here, are they inherit to how Java itself? Is it baggage from Spring/Boot? Are there ways to get more bang for the buck with some careful choices in a system like this? The closest I’ve done to Java recently is C#, which I think may have similar challenges, but overall didn’t se…
Having done a lot of Java and Go, Go has much better mechanical sympathy between the language, libraries, and vm than Java does. The JIT GC in Java are marvels of engineering, but they have to be.
As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc. In Go, there is first class support for composition.
The other main adjustment, if coming from Java, is reduced cognitive overhead. It usually only takes a week or two for an experienced Java dev to be reasonably effective in Go, but it takes a few months to break the mental habits of overthinking everything.
Re: One year after switching from Java to Go
#16Earlier quoted context omitted.
Spring by far - Spring is effectively a build tool running at run time (scanning, enhance, code generation, etc.) - most of it is just startup as JVM does a decent job at optimizing the cruft. In most cases the boot times don't matter, though - at least for most people, esp. when it comes to production. (it's mostly developers time wasted) I have some personal experience optimizing Spring to record previous runs and…
> most of it is just startup Yep, I have some Spring code in AWS ECS and it hits 100% CPU usage on start-up before dropping back to 1.5% when idling (this is with 1 vCPU I think). But yeah I remember reading one of the Spring devs say that some (a lot?) of the runtime reflection could be done at compile time but isn't.
> Spring devs say that some (a lot?) of the runtime reflection
It's a lot more than reflection, if it'd have been reflection alone - it'd be markedly better. (and yes, lots and lots can be optimized). Spring effectively:
scans the classpath for resources - that includes jars, file system
loads every single class matching the scanned directories as a byte array
parses it in java (not by JVM) to check what annotations it has (it doesn't load the classes actually)
builds dependency tree
enhances the previously loaded byte arrays, i.e. generates different byte code
loads the newly enhanced classes and create instances (usually through standard reflection)
makes calls like PostInit (life cycle)
in some cases it uses the standard java reflection to set fields/call methods; in lots of cases java reflection is generating (and loading) a new class (byte code) to carry the process
as for the 100%, spring initialization is mostly single threaded - so likely you dont have many cpus dedicated to the java process. (or you meant just a single core 100%)
Re: One year after switching from Java to Go
#17Agree. Go is a joy to use. Java is okay but struggles with scaling unless you have the money to burn for this. To scale up servers in Java requires spinning up highly priced servers with lots of RAM, which that is a lot of money. Using a low spec server is cheaper but you will get more JVM crashes and have to waste time doing more JVM tuning to prevent them. This is not even talking about having lots of 'microservice…
> Would stay really far away from JavaScript or TypeScript for anything backend.
IDK, TypeScript types are extremely ergonomic, and if you're not overzealous makes everything very readable, and given many things are I/O bound anyway, it doesn't matter much.
Re: One year after switching from Java to Go
#18> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application.
Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but this breaks down when data is hidden inside a context. Dependency injection is entirely possible without using the context package at all, interfaces are great for it.
Re: One year after switching from Java to Go
#19I long for a deep article about the same topic. The real, core difference between Java and Go for backend is declarative vs imperative coding styles. This one, as typical for such articles, repeats typical secondary talking points and even makes similar mistakes. For example it conflates the concept of DI with specifics of implementation in some frameworks. Yes there are older Java frameworks that do runtime magic. B…
Which of these languages is declarative? Aren't they both imperative?
Re: One year after switching from Java to Go
#20seems to be mostly criticism of spring rather than java
the company behind spring should ruin go by porting their crappy library to it
(oh look, it's broadcom....)