One year after switching from Java to Go

https://glasskube.dev/blog/from-java-to-go/

by pmig • 1 year ago

257 470 1 year ago

honkycat2• 1 year ago

After dealing with constant build issues between Java and Typescript and Node and Python: I love go so much. The package management alone makes it worth it.

scubbo4• 1 year ago

After dealing with constant build issues with Go, I hate Go so much. The fact that they've conflated "source code" with "consumable library" means that you need a special case in your CI to publish new versions of a library in Go vs. every other language that builds and publishes an executable, and any tooling that pulls from a private repository has to hack `git config` rather than authenticating like you would any other artifact repository.

And that's before we even get onto the "v2" nonsense[0], because apparently it's unidiomatic to continue developing your packages after you publish them. Actually.....given that this language arose at Google, I may be onto something...

[0] https://go.dev/blog/v2-go-modules

diamondfist25• 1 year ago

Btw js/ts, python, and golang, which one do you find more productive with?

throwaway894345• 1 year ago

I’m confused by this. Go doesn’t have a “publish a library” step, whereas every other language does. Is “noop” the special case you are referring to? And why are you comparing publishing a library in Go to publishing executables in other languages?

unidiomatic to continue developing your packages after you publish them

Are you talking about publishing breaking changes without bumping the major version? Because that seems … like a bad idea in any language?

pseudoramble• 1 year ago

I’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 seem quite as bad if you avoided lots of framework extras. It also wasn’t something I was digging into deeply though, so perhaps I’m mistaken.

xxs3• 1 year ago

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 effectively cache resolution and code generation, etc. for massive boot latency improvements. Never got around contributing it back, though (not a real spring user)

jamesfinlayson2• 1 year ago

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.

voidfunc• 1 year ago

You can write clean beautiful Java and make it perform beautifully if you're careful with what you pull in for dependencies... but then you're not really using Java to its full potential as an ecosystem for basically building massive line of business apps and services that you can spin up everything from junior to offshore to 30 years of experience developers. The tradeoff for this is performance and it's a thing a lot of companies are willing to trade off on.

Things get messy the moment you involve large frameworks, reflection, ten different approaches to parallelism etc. There's also the problem of code base evolution in Java. Code before JDK-8 feels different than code after it and there's a lot of Pre-JDK 8 code out there in the wild.

And that's just it at the end of the day... it's a cultural difference in the ecosystems.

gred• 1 year ago

My experience with very simple Jersey web apps is ~1.5 seconds to start up. Much less than his reported ~8 seconds with Spring Boot, but still not in the 100 ms range he reports with Go. I assume one second or so is about as low as you can go with a mainstream Java framework without AOT, though I'd be happy to be corrected.

maccard4• 1 year ago

I worked on an app in kotlin a while back, and am currently working in a dotnet app. We can run our entire unit test suite faster than the JVM started up on that project.

Also, 8 seconds is quick in my experience for Java - I’ve seen more like 15-30

p2detar2• 1 year ago

Can confirm with Vert.x. I used to have a JRebel subscription for code hot swapping in another project but in my current Vert.x thing I simply don’t need it. It’s just fast.

matsemann2• 1 year ago

Also, you don't have to continuously restart the server for every change. Can hot swap code. And for tests there are solutions to keep the jvm running between the code->test->fix cycle. But I've never felt the need for those, running a single test is often plenty fast as one doesn't need to instantiate the whole app, only the dependencies needed for the test. So plenty fast.

nelup20• 1 year ago

You can do AOT compilation with GraalVM to reduce both startup times and memory usage, but then you don't have the JIT.

e44858• 1 year ago

I think this upcoming feature will let you have both AOT + JIT without needing GraalVM: https://wiki.openjdk.org/display/crac

tomohawk• 1 year ago

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.

codr76• 1 year ago

There's nothing forcing you to write EE style code in Java though, or depend on frameworks written in that style.

re-thc2• 1 year ago

As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc

Strictly speaking that's not true. It's everything is a pointer in theory to make it easier to reason with and JIT / JVM optimizing in the background.

There are primitive types and there are lots of tricks in the JVM e.g. escape analysis that places objects on the heap/stack etc.

jeroenhd• 1 year ago

In my experience, if you write Java like you'd write to, you'd probably get similar performance. Maybe AOT performs a bit better, maybe it doesn't because it disables live optimizations.

Java doesn't lend itself well to writing Go style code, though. You quickly end up writing very "Java" Java code. That has some advantages (code deduplication, less boilerplate) but also downsides (allocation overhead, performance impacts).

In terms of Java vs C#, I don't think you'll notice too many new issues. If you opt into using heavy frameworks like Spring Boot to solve annoying problems for you, you'll see RAM usage increase massively, but it'll also take care of a lot of annoying grunt work for you. Startup times overall are pretty similar. The biggest downside in my experience is the lack of nullable types (@Nullable annotations are a poor substitute) and some syntax improvements that are new to Java but have been part of stable C# for many years.

As long as you stick with small libraries and avoid writing too much ObjectInjectorFactoryProducerResolver style code, performance of the JVM is fine.

All of that goes as long as you're able to use modern toolkits. If you're stuck in the world of Enterprise Java with Oracle Java 8, you'll notice old Java's shortcomings a lot more.

heluser2• 1 year ago

I 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. But both new Java apps and well designed Go services use compile time dependency injection as a way of achieving dependency inversion.

jayceedenton• 1 year ago

Which of these languages is declarative? Aren't they both imperative?

CharlieDigital14• 1 year ago

Maybe Java when using decorators?

heluser2• 1 year ago

Java 8+ is basically a declarative language. They even officially started departing from Object Oriented Programming towards Data Oriented Programming ( article by their chief architect https://www.infoq.com/articles/data-oriented-programming-jav... ). Unfortunately, most of the comparison articles come from people who still code POJOs with setters, use for loops and overall rely on mutable and unsafe code.

And using Pike’s own words “go is unapologetically imperative”.

golly_ned• 1 year ago

Write that article then. Don’t badmouth the writer’s firsthand (evidently not secondary) experience over the course of a year since they didn’t express your idiosyncratic view that Java is a Declarative Language, which is very different from a data-centric language, which itself is a term from the clojure/scala enthusiasm about functional programming around Java 8.

yodon• 1 year ago

Has anybody spotted a similar story of switching from C# to go?

As someone who is very fond of C#, I'm definitely curious what I'm missing out on.

fullstackchris3• 1 year ago

Probably if you are fond of C# you wont like Go. I've always found C# incredibly verbose and full of all sorts of syntax sugar (that they add to yearly) making code everywhere look different, just enough to add a little cognitive overhead... Go on the otherhand, is purposefully opinionated and forces one more or less to write Go in a certain way.

neonsunset4• 1 year ago

It’s mostly the other way around. Go is a strictly worse, caveman experience after C#. In it’s best moments, Go is a sidegrade at most.

fullstackchris3• 1 year ago

Go look at httpclient for .NET core 4.8

I mean, just the star count on GitHub is enough to show what the developer community thinks.

WuxiFingerHold• 1 year ago

I've used C# years ago, then some Go for simple web services and CLIs and now I'm back at C# for those applications. You're missing out nothing if you're already familiar with C#. Go's biggest advantage is that it's much simper to learn. The whole experience feels much more lightweight and straight forward. Very easy to navigate the ecosystem.

Other than that, modern C# and .NET has the edge over Go almost everywhere. Good examples are obviously LINQ, null safety, extension methods, the type system in general, on the .NET side Generic Host (.NET standard solution for DI, config and logging for all kind of apps), Minimal API, EF Core, and performance. Memory usage for AOT is also very low, Go might have the edge here.

mattgreenrocks4• 1 year ago

Currently learning ASP.NET Core, seems very well put together with quality first-party libraries. I miss Kotlin, but I suspect ASP.NET Core and Blazor SSR makes up for that.

Particularly excited by the fact that Blazor SSR lets you write server-side components. So I can have a statically typed language that lets me think about the UI in terms of components, and a DI container on hand for when I want to break business logic out into services. Love the flexibility all of those things coming together affords. EF Core seems really promising for persistence so far, though I need to play with it more.

Playing with their Identity framework last night I was able to get up and running despite being new to the ecosystem. Very good sign, most of the time integrating auth as a newcomer to a lot of languages ends up being way more than 2 hours worth of work.

pm902• 1 year ago

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.

MarkMarine4• 1 year ago

You can AOT compile Java just like go:

https://news.ycombinator.com/item?id=30859013

skeeks• 1 year ago

There are a lot of applications where the startup time of several seconds does not matter at all. More likely, for most applications it does not matter. Of course, if you are FAANG, it does, but you should not optimize for that in the beginning.

pm902• 1 year ago

I have never worked for Faang and have seen this be an issue in every single company Ive worked for. Every one. You don’t need millions of pods. Even a fleet of a few hundred (which isn’t crazy for most small to medium businesses) will cause you much pain if you don’t handle this properly.

rvz• 1 year ago

Agree. 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.

amazingamazing9• 1 year ago

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.

CharlieDigital14• 1 year ago

Big problems for APIs though because TS types disappear at runtime.

So now you need to add in Zod or Valibot as well to validate your types. If you have view models and DTOs, then you add more Zod. Might as well use a statically typed language?

Working with OpenAPI is much easier when you already have a static type system.

How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.

Would not build backends in TS except for true microservices. The ergonomics of a Nest.js vs .NET Web API are night and day.

bdhcuidbebe3• 1 year ago

I guess you just dont know the domain well enough to understand the kind of issues strong typing and compiled software is solving.

deepsun• 1 year ago

Seems 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.

winrid6• 1 year ago

Probably it only uses 100mb of heap but they didn't check or tune the memory manager at all

bryancoxwell• 1 year ago

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.

MrDarcy3• 1 year ago

I hit this point in tfa and had the same comment. Please don’t pass things around in a Comtext. Maybe stash a slog logger in there, but that’s about it.

I made the switch to Go a few years ago. For those who are on a similar journey as the author, or the author himself, I suggest spending time with the Go standard library and tools written by Rob Pike and Russ Cox to get a handle on idiomatic Go.

It’s clear the author still thinks in Java, not go. Saying Context ctx for example instead of ctx context.Context. Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work.

I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

Edit:

Regarding stack traces, it turns out you don’t need them. I strongly suggest a top level error handler in Go combined with a custom error struct that records the file and line the error was first seen in your code. Then wrap the error as many times as you want to annotate additional lines as the error is handled up to the top level, but only that first point in our own code is what actually matters nearly all of the time.

arnath• 1 year ago

This comment is about a very minor part of what you said, but isn’t the whole point of a DI framework to write code you’d have written anyway to save you time?

mukunda_johnson• 1 year ago

I prefer stack traces in errors. It's gives so much more automatically so you don't have to worry about manual annotation. Stack traces and debug logs are the way to go. I like to use panics for exceptional conditions just for the convenient escape with the stack trace.

nine_k2• 1 year ago

The exact stack trace may not be very necessary, but tracing the chain of calls, especially async, can be hugely helpful in troubleshooting, performance tracking, etc.

In Node, I remember wrapping Promisesromises into objects that had a stack for pushing messages onto them, so that the creator of a Promise could mark the calling site, and creating another Promise within that promise would pick up the chain of call site names and append to it, etc. Logging that chain when a Promise fails proved to be very useful.

nesarkvechnep• 1 year ago

I’m yet to see a former Java developer who uses the idioms of the language they currently use. They all just write Java in a different language.

akoboldfrying3• 1 year ago

Regarding stack traces, it turns out you don’t need them.

goes on to suggest rolling your own buggy, slow, informally specified implementation of half of a stack trace printer

_w1tm• 1 year ago

Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap implementations.

DI does not require any framework and I would argue you can’t write modular code without it. Most likely you are doing DI even in your manually written code.

eximius• 1 year ago

spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

Yes, but the point is 1) you don't have to write it yourself and 2) it does 'the right thing' even if your junior dev straight out of BS CS wouldn't know how to write it.

There are, of course, caveats and not all frameworks are created equal and any tool can be misused. But I find DI very useful. Personally I'd recommend Uber's Fx framework and underlying dig library.

fweimer3• 1 year ago

How does Go avoid getting bogged down by middleware-oriented programing in practice? I think most large-scale programming in organizations tend to converge on that because it sort of works.

Is it that people who like this kind of stuff write microservices for deployment on Kubernetes clusters?

nprateem4• 1 year ago

Regarding stack traces, it turns out you don’t need them

Then you go on to explain how to recreate them by hand.

saturn_vk2• 1 year ago

Maybe stash a slog logger in there, but that’s about it.

Please don't do this either. Read the stuff you want to log as additional attributes in your slog handler from the context, which you ultimately pass to `slog.*Context`

saturn_vk2• 1 year ago

Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work.

DI is necessary in every language that doesn't rely solely on global singletons. Passing dependencies as arguments to a function is DI.

What may not be necessary, are IOC containers automatically create objects and satisfy their dependencies.

Cthulhu_4• 1 year ago

Then wrap the error as many times as you want to annotate additional lines as the error is handled up to the top level

I'd add that this is a last resort; errors should be handled and resolved as close to where they occur as possible. Having them bubble up to a central error handler implies you don't really want to do anything with it.

jbreckmckye• 1 year ago

Regarding stack traces, it turns out you don’t need them. I strongly suggest a top level error handler in Go combined with a custom error struct that records the file and line the error was first seen in your code. Then wrap the error as many times as you want

So instead of a stacktrace, you are - tracing the stack? Am I understanding correctly?

Because it just sounds like a manual version of stacktraces

mexicocitinluez2• 1 year ago

I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

This is like saying "I won't use source generators because it generates code I would normally write myself"

Like, yea no shit. THAT'S the point.

cflewis3• 1 year ago

FWIW the internal Google style guide says to not pass anything via Context unless you _really_ know what you're doing and why. Things that make sense: security tokens and tracing. Things that don't make sense: almost everything else.

throwaway203710• 1 year ago

    > internal Google style guide

Can we read this somewhere?

Ferret7446• 1 year ago

Context is just thread local storage aka dynamic scoping aka global variables.

It is useful for some things, particularly middleware that needs to cross API boundaries.

https://www.felesatra.moe/blog/2019/12/01/transiting-apis

nine_k2• 1 year ago

Implicit shared state? Exactly the thing to enjoy in a highly concurrent environment!

At least I hope that a context can be immutable throughout. I only see one variable in the documentation of the context package. Extending it with mutable fields, and mutating them to pass data between functions, would be something I'd never approve in a code review.

cyberax• 1 year ago

The context itself is immutable, it's essentially a linked list (or actually a tree). If you need to "mutate" it, you create a new segment that links to a previous segment.

throwaway203710• 1 year ago

    > 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

This is not possible in Java or C#? Both of those languages are so simple to grasp.

zdragnar• 1 year ago

The languages aren't, strictly speaking, so much the problem as are the massive frameworks configured via distant files with lots of DI and reflection magic involved.

Go has some large frameworks, but the community frequently suggests they aren't needed and that the standard library is enough.

lelanthran2• 1 year ago

This is not possible in Java or C#? Both of those languages are so simple to grasp.

Not really, no.

Apart from the cognitive burden of knowing the test framework in use, the DI tooling in use, the Mocking framework in use, plus all the annotations that each framework may want/need, almost none of which applies to the Go projects I've seen, the languages themselves have drifted away from simplicity.

I used to program in C# but left it for a long time and only recently looked at it again. C# is approaching C++ levels of syntax indecipherability.

rapsey• 1 year ago

Programs written in those languages tend to have many layers of abstractions, on top of abstraction heavy frameworks.

nprateem4• 1 year ago

Try understanding what spring boot is doing. Annotation soup. It's practically impossible for a beginner to Spring to debug.

rendaw• 1 year ago

How are interfaces a replacement or improvement to context? Is it just that they're type safe?

roncesvalles5• 1 year ago

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store.

Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies, call init() in topo order, and other such things.

Test using monkey-patching. Stop using interfaces just to be able to swap a real thing with a mock implementation. These are all symptoms of writing Java in Go.

3uler• 1 year ago

And yet Uber wrote fx[1] to support DI in their golang services. It’s clearly a useful pattern when working on large services.

[1] https://github.com/uber-go/fx

someothherguyy• 1 year ago

So, write python in go instead, gotcha.

stpedgwdgfhgdd• 1 year ago

I don't get the part on package. Often you want to use structs. (Instance vs static)

How would you construct an instance in a test that needs mock implementations?

akoboldfrying3• 1 year ago

Test using monkey-patching.

TIL Go has monkey-patching.

But since it has monkey-patching, how is it statically typed? Or does Go monkey-patching amount to creating an instance of a defined-on-the-fly subclass?

The latter would be interesting, because Java lets you do this too -- conveniently "new up" an instance of a subclass that you define inline of a given class or interface (this used to be the easiest way to define callbacks, before lambdas came along), so this testing strategy is available to Java too, but seems not to be preferred.

Separate question: IIUC, monkey-patching is convenient if your test code directly needs to create a TestX instead of a real X, but what if you need the test double "deeper down" -- that is, you need an X that creates a Y that creates a TestZ instead of a real Z?

the_gipsy• 1 year ago

Test using monkey-patching.

Can you elaborate? What library do you use?

captain_coffee• 1 year ago

Hard disagree to literally every thing that you have said in your reply above.

geitir• 1 year ago

Also https://github.com/uber-go/fx

blibble• 1 year ago

seems 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....)

MarkMarine4• 1 year ago

Have you seen Fx (uber dep injection for go)? If you want to have the imprint of your keyboard on your forehead, try to get a complex Fx app working after you’ve refactored. Pure, absolute misery. I yearn for dagger every time I touch the system that has it, but black magic that my IDE understands is a close second dagger compared to a dep graph that you can only figure out if it’s correct by running it. Real fun on a go app that can’t be run locally.

computerdork4• 1 year ago

Agreed, the spring framework is completely against the spirit of Java. Yeah, auto-wiring was a terrible idea - why do I have to guess what components are going to be pulled in? And why do I have to figure this out a runtime?

The features of Spring Boot are nice, but Spring itself should probably be put out to pasture. Someone needs to write a good alternative to Spring and start promoting it like crazy (probably something exists).

bdangubic3• 1 year ago

went to springone conference in vegas in 2016. eight years later, there are still no good alternatives :)

epolanski2• 1 year ago

Very ignorant about Go, is dependency injection not a thing there?

E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them.

I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted and provided at runtime (or compile time, depends) with the repository pattern. How's that useful? Developers can use a filesystem-based database when working, and don't need to setup docker images that provide databases, anything they do is saved on their machine's filesystem. E2Es can run against an in-memory database, which makes it very simple to parallelise tons of different tests as there are no race conditions. And yes, the saved formats are the same and can be imported in the other databases, which is very useful for debugging (you can dump the prod database data you need and run it against your implementation).

There's many other situations where this is useful, one of the core products I work on interfaces with different printing systems. Developers don't have printers at home and my clients have different printing networks. Again, abstracting all of it through DI makes for a very sane and scalable experience.

I don't see how can this be achieved as easily without DI. It's a very nice tool for many use cases.

tymscar• 1 year ago

Totally agree with you, but one point against doing what you mentioned is that you want to replicate your prod environment as much as possible in CI, to be able to catch bugs

epolanski2• 1 year ago

From my experience this has been mostly painless, and yes, in CI you can obviously run against environments using the same stack as prod.

It may help that I'm writing plain old boring ecommerces or internal tools (scrapers, chatbots, backoffices, warehouse management, delivery systems, etc) and not something more complex and low-level like databases or rendering engines.

gt0• 1 year ago

DI exists in Go, but it's not ubiquitous like it is in the C# or Java worlds.

Last time I used Go, I used "wire" for DI and was pretty happy with it.

cflewis3• 1 year ago

I worked on Wire right at the beginning, happy to answer any questions about it.

dgunay2• 1 year ago

DI in its most fundamental form is common in Go via interfaces. People just declare that arguments to their functions must implement some interface, and the caller provides something that satisfies it.

"DI" in the sense of having a more complex purpose-built DI container is less common. They exist, but I don't see them used a lot.

If your application code has a ton of dependencies, the direct injection/low magic style favored by Go can get kind of boilerplate-y. I'm not going to comment on which style is better.

CharlieDigital14• 1 year ago

.NET's DI has constructor injection so I suppose this is similar; you just write your constructor saying "I need an `IDataProvider`" and it can come from DI or direct.

Question I have for Go though. Without DI, what is the idiomatic way of supplying one of n implementations? An if-else block? Like if I had 5 possible implementations (AzureBlobStore, AwsBlobStore, GcpBlobStore, CFBlobStore, FSBlobStore) and I need to supply 10 dependent services with access to `IBlobStore` what would that code look like?

In .NET, it would look like:

    // Resolve the concreteImpl in DI
    IBlobStore concreteImpl = switch (config.BlobStoreType) {
        case "Azure": new AzureBlobStore();
        case "Aws": new AwsBlobStore();
        default: new FSBlobStore();
    };

    // Register
    services.AddSingleton<IBlobStore>(concreteImpl)
    services.AddScoped<Svc1>();
    services.AddScoped<Svc2>();

    // Services just use primary constructor and receive impl
    public class Svc1(IBlobStore store) { }
    public class Svc2(IBlobStore store) { }

    // But I can also manually supply (e.g. unit testing)
    var mockBlobStore = new MockBlobStore();
    var svc2 = new Svc2(mockBlobStore);

MrDarcy3• 1 year ago

DI is generally not an explicit thing in Go. As a sibling comment mentioned, there is wire but it simply generates code, it is not a runtime DI framework like Spring has. This is a feature. The code wire generates is the same code you’d normally write, which is what makes it unnecessary for many projects.

Go has interfaces natively which are implemented in a different way. We never need to say X implements I like we do in other languages. X either satisfies the interface or it doesn’t and the compiler and editor catch this fact early.

So, you’d simply declare an interface to define the API you described in Go, no need for DI or anything else.

bob1029• 1 year ago

DI at its most fundamental interpretation is the act of passing (injecting) arguments (dependencies) to functions.

Nothing stopping you from doing function-level "injection" of generic or interface type arguments. In this context, function could include the ctor.

alexjplant• 1 year ago

Very ignorant about Go, is dependency injection not a thing there?

It is but there isn't a heavy emphasis on a DI framework per se. At its core DI is "inversion of control" insofar as an object constructor receives what it needs to do its job as opposed to the constructor instantiating said requirements itself. In my experience Golang devs don't use of a bunch of meta-programming via tags/annotations/decorators to tell a third-party framework what reflect-y magic it has to do at runtime; they typically just abstract everything behind an interface and pass instances of what you need to a New function that instantiates the consumer object. I personally prefer this to Spring-type frameworks because it's more verbose and checked at compile time. This means one can easily follow what's going on instead of having to dig through a bunch of nested stack traces riddled with Aspect4J esoterica to find out why some magical Maven dependency suddenly broke your entire app for no reason at all.

Then again the last time I had to bootstrap a complex Spring project was in 2014. Since then I've used Spring Boot for simple 3-tier microservices and it worked fine... it's likely improved since then but I still wouldn't use it for anything greenfield after the loop it threw me for.

smrtinsert2• 1 year ago

I thought we had moved on from flame bait articles as a species

MarkMarine4• 1 year ago

I work with a brownfield go monorepo with a couple different styles and lesser known “frameworks” in it. It sucks to work in, one of the previous devs was a huge fan of clean code, so every function with more than a couple inputs has its own struct, pointers are used everywhere just by default (and basically never nil checked) and the AI generated tests are so plentiful that changing a small thing quickly explodes into thousands of lines in of changes.

Because it’s go and not really following a framework or pattern, the LLMs just can’t get the style right, so everything is brute force. Know what is easy to build with an LLM? A spring boot app. You can work on the hard logic while your little automated friend works on all the boiler plate and wiring.

rollulus2• 1 year ago

Disasters can be created in any language, right? Has little to do with Go.

matsemann2• 1 year ago

True, but most of the arguments against java in this thread are similarly about bad dev practices and not the language itself.

evil-olive2• 1 year ago

it's really weird to see a "Dependency Injection & Context" section as if Golang's context has anything at all to do with DI.

in particular, reading between the lines here:

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.

suggests to me that they've implemented one of the Golang anti-patterns that I find most annoying - overloading the context and using it as "grab bag of pseudo-global variables"

in this anti-pattern, you have an HTTP request handler, and want to make a database query, so you need access to the database connection pool. having a global variable for the connection pool feels wrong...so what many people do instead is call context.WithValue in their server startup code to put the connection pool into the grab bag, and then in the request handler call ctx.Value to pull the connection pool out of the grab bag.

the Golang docs [0] explicitly say not to do this:

Use context Values only for request-scoped data

the much better way, in my experience, is to make the request handler a method on a struct, and then the struct holds references to things like the connection pool. this can also be done with closures and captured variables, of course, but that tends to get unwieldy for non-trivial usage.

if you do this, then your "dependency injection" in Golang tends to look pretty much identical to how it would look in Java, if you wired everything up by hand rather than using a framework/library. and then if you want, you can use a library such as Fx [1] for automatic Dependency Injection along the lines of Spring Boot.

0: https://pkg.go.dev/context#WithValue

1: https://github.com/uber-go/fx

paulddraper2• 1 year ago

as if Golang's context has anything at all to do with DI

Yes, Go's context can be used as a DI container.

tomcam• 1 year ago

I thought it was mostly used to terminate an asynchronous event?

evil-olive2• 1 year ago

Go's context can be used as a DI container.

the WithValue/Value API allows you to treat the context as essentially a map[string]any. [0]

so if you want to make the definition so expansive as to be meaningless, then yes, map[string]any can be used as a "DI container". and so can a context object, because it exposes a map[string]any-ish API.

0: though if you read the implementation [1] looking up a value in a context is essentially a linked-list traversal and not a hashtable lookup

1: https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/...

blindriver2• 1 year ago

I've been using Go for a while now. The biggest headache is error handling. I don't care what the "experts" say, having exception handling is so, so, so much cleaner in terms of error handling. Checking for err is simply bad, and trickling errors back up the call stack is one of the dumbest experiences in programming I've endured in multi-decades. If they are willing to add generics, they should add exception handling as well.

BytesAndGears• 1 year ago

Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?”

Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle.

The thing that always happens with exceptions in API projects I’ve worked on, is that exceptions can come from any level of the stack, then by default it skips everything in the middle, and the controller has default handlers for what to do in case of an exception.

If there are exceptions you didn’t know existed because of some library or just complex code with dozens of possible exceptions? They still end up being handled in your controller. You need to know exactly what exceptions could happen at every level of the stack, and how to handle it, otherwise everything just short circuits.

With the go errors, you only need to know “did this function call work? If not, then what?”

hedora2• 1 year ago

Exceptions are a terrible idea.

However, I strongly prefer rust error handling to Go.

go:

   (res, err) := foo()
   if err != nil
       return err
   (res, err) := bar(res)
   if err != …

Equivalent rust:

   let res = bar(foo)?)?;

I think go should add the ? sigil or something equivalently terse.

Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possible in idiomatic rust.

bmurphy1976• 1 year ago

To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.

CharlieDigital14• 1 year ago

What challenge did you run into with exception handling?

I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions.

The only case where I might add explicit exception handling probably falls into a handful of use cases when there is a desire to a) retry, b) log some local data at the site of failure, c) perform earlier transform before rethrowing up, d) some cleanup, e) discard/ignore it because the exception doesn't matter.

codr76• 1 year ago

Agreed, every time I jump back into Go I'm at first relieved at how nimble it feels; but it never takes long to remember what a pita error handling is or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).

throwaway203710• 1 year ago

    > or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).

Why hasn't anyone written a good open source for this problem, now that Go has generics?

rollulus2• 1 year ago

I guess I won’t be adding new information to what your “experts” said as well, but hey. I love Go’s error handling. Syntactic sugar like in Rust could’ve made things a bit nicer to they eye, but apart from that: being forced to think about each error path leads in my view to better code. Compared to a fat try/catch and fingers crossed that all goes well in it.

owlstuffing4• 1 year ago

Going back to first principles, nominal typing is what I miss most with Go. I get the utility of structs + interfaces + structural typing, but most of the time there is more benefit in declaring that a type nominally implements an interface when that is the intention. Code is far easier to read and understand that way, both for developers and tooling.

I suppose exclusively structural typing would be more acceptable if Go supported _real_ interface composition, like Scala with traits or true delegation via the manifold project[1] for Java. But that's missing as well e.g., does not inherently fix the Self problem, etc.

Considering Go's initial goal, which was IIRC a better systems language, then yeah, sure it's an improved C. But now that Go is routinely compared with Java/Kotlin and friends, I personally don't see it, particularly wrt the type system, to be taken seriously as a Java contender. Shrug.

1. https://github.com/manifold-systems/manifold/blob/master/man...

dagss• 1 year ago

Are you aware of the trick of "var _ foo.RequiredInterface = myType{}" to make the compiler enforce that a struct implements a given interface?

Is what you seek a nicer syntax for this or does what you speak of bring something more feature wise?

At least IntelliJ IDEs will always make it clear what interfaces all your structs implement.

owlstuffing4• 1 year ago

Are you aware of the trick

Yes, and while it uses the compiler to ensure a type implements an interface, it's still a trick that exposes a large hole in the language... and begs for it to be filled. Most importantly, it still doesn't make the code much easier to read and understand.

At least IntelliJ IDEs will always make it clear (or less foggy)

Indeed. Go benefits hugely from IntelliJ, or to be specific the IJ plugin API.

throwaway203710• 1 year ago

    > But now that Go is routinely compared with Java/Kotlin and friends

Do you think Go is "moving up" (away from systems prog) or is Java "moving down"?

owlstuffing4• 1 year ago

Do you think Go is "moving up" (away from systems prog) or is Java "moving down"?

I haven't been keeping score, but I've read other articles like this one claiming Go as an enterprise language alternative to Java. Not much concerning Java as a systems language, but that makes good sense. I see Go v. C/Rust, not Go v. Java/Kotlin. Just my take.

_ph_• 1 year ago

While having to declare the interfaces a type implements can increase the readability, it comes with a huge drawback: you are limited to implementing the interfaces considered when writing the code. In my eyes it is a fascinating and important feature that you can add interfaces and all existing types automatically implement them, if they, by their methods signature, implement them. You don't have to edit their type declarations to do that.

owlstuffing4• 1 year ago

it comes with a huge drawback: you are limited to implementing the interfaces considered when writing the code

Huge drawback? Quite the opposite. Unintentional implementation is a terrible trade for readability and type-safety, hence the trick the prior commenter mentioned.

In fact, structural typing is best when limited to the far less used case where an interface is designed to reflect functions from existing types. It's useful here, otherwise it's a hinderance for the primary case where a type _intends_ to implement an interface, which is what nominal typing is for.

Go was designed as a systems language, and the choice for structural typing served that goal in terms of performance enhancements. But used as a general purpose language, as the trick above (and others) demonstrate, Go's structural typing is less suitable compared with nominal typing.

TheCycoONE• 1 year ago

We run mostly Java apps with a few Go apps. What I miss with Go, maybe just because I'm not as familiar and don't know where to look, is all the runtime analysis that's built in. Thread dumps, heap dumps, and even flight recorder profiling is all built in to the JVM so it works with all apps everywhere. When a Go app suddenly slows down it's very difficult to determine why unless the app was coded to provide the right metrics.

burch45• 1 year ago

I actually much prefer go ‘s runtime tooling. Pprof has everything I need built in; heap, cpu, blocking, mutex contention. And don’t need additional tools to visualize the collected data. https://pkg.go.dev/net/http/pprof@go1.24.0

cmrdporcupine2• 1 year ago

I haven't done Java fulltime in almost 15 years, but I still haven't seen anything out there that is as good as JMX was, out of the box. For just getting decent metrics / observability without rolling in frameworks. Just part of the runtime.

metaltyphoon2• 1 year ago

Does pprof work when CGO is enabled?

philipwhiuk2• 1 year ago

As a Java developer...

If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'.

Java is good right now because most problems have libraries to do what you want. Most formats have APIs.

It's not perfect in any area - the start-up time is a bit lame, you have to write 'anti-Java' to really get close to native performance. But it's quick to build in, the toolchain is solid, the dependency framework works better than all the alternatives. It's a 95% language that's been made development friendly.

(Golang somehow added versioning late and is 'Git+' at best, NPM unpublished stuff, C++ is hell, etc. Rust crates just doesn't have much but seems to have been built properly).

But if you're working in a new space (crypto, AI, cloud) then you should definitely look at what the state-of-the-art libraries are written in.

And you should think real hard before you implement your app in anything else. Because there will be a real, long term, painful penalty unless you get VERY lucky and the entire ecosystem pivots to your language.

pylua8• 1 year ago

I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a tight game loop.

The startup time is also a real problem, as you really want to be able to scale up pods quickly.

That said, it’s good enough right now. You can make it work at scale, and it’s worth the cost trade off of trying to do it more efficiently in a different language.

I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze?

cmrdporcupine2• 1 year ago

Most "microservice" backend type stuff is I/O bound, not CPU bound. You're likely not going to win much.

Maybe get away with lower memory instances though.

throwaway203710• 1 year ago

    > I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze?

So, replace cheap Java developers for expensive Rust devs to squeeze out some savings? It makes no sense to me.

rootlocus• 1 year ago

Have you tried AoT compilation with graalvm?

znpy• 1 year ago

The startup time is also a real problem, as you really want to be able to scale up pods quickly.

I was learning a bit of spring last week and a spring boot web application, generated via the web interface boots in like 800msec:

    ...
    Initializing Spring embedded WebApplicationContext
    Root WebApplicationContext: initialization completed in 339 ms
    Tomcat started on port 8080 (http) with context path '/'
    Started DemoCourseApplication in 0.746 seconds (process running for 1.012)
    ...

Reusing my experience from other technologies... I'd say the issue might be in whatever you're doing in your initialization and/or how much stuff you're loading.

Looks like the core spring is decently fast, to me.

gf00028• 1 year ago

Could you expand on "how bad the performance can be" part?

If you are doing graphics, it is entirely more likely that you do something dumb there - there are many pitfalls.

Also, unless you are doing something very CPU-heavy, there won't be any noticeable difference as web servers are doing IO predominantly. Maybe slightly less RAM usage (but you could also just decrease the heapsize to tradeoff a bit of CPU-time for memory, if it were to make sense).

conwaytwitty2• 1 year ago

Spring Boot startup time is indeed a problem, especially when scaling horizontally on low cpu nodes.

If your environment allows for burst cpu usage until ready to accept traffic, you can start up really fast as spring does so much reflection magic during startup that can't be done during compilation "trivially". You can include hints for runtime configuration from a build, but it doesn't do much to help in really low cpu envs.

Then you can of course just do native images, but you lose some of the spring "magic", and might be annoying to refactor towards.

marginalia_nu2• 1 year ago

Writing high performance Java is definitely a bit of a dark science, a lot of the performance isn't just the code loop you're looking at, but memory allocations matter quite a lot as well. Complex hierarchies of large long lived objects can absolutely tank your performance.

There can also be a lot of performance to be gained by going off heap. I'd be probably be looking at an ECS design around MemorySegments, rather than modelling the game state with Java objects. Though, to be fair, this is how you'd write a game engine in C++ as well.

throwaway203710• 1 year ago

Yeah, language ecosystems get no love here. Part of me dreads Java, but the developer experience is mostly worse elsewhere.

jillesvangurp2• 1 year ago

I made the switch to Kotlin around 2018; after having been using Java since 1995. Java is a choice these days, not a necessity. Kotlin is a drop in replacement for Java in 100% of it's core use cases. No exceptions that I know of. Doesn't matter whether you do Android or Spring Boot. It kind of does it all. And it's actually really good at dealing with creaky old Java APIs. Extension functions (one of the party tricks modern Java hasn't yet picked up from Kotlin) are amazing for adapting old code to be a bit less tedious to deal with.

You don't really lose anything (APIs, tools, etc.); but you gain a lot. I still use Spring. But I've now used it longer with Kotlin than with Java.

And the nice thing with Kotlin is that it is gaining momentum as its own ecosystem. I'm increasingly biased to not touching old school Java libraries. Those lock me into the JVM and I like having the option of running things in wasm, in the browser or on mobile. Our frontend is kotlin-js and it runs a lot of the same code we run in our Spring Boot server. Kotlin multi platform is nice. I've published several libraries on Github that compile for platforms that I don't even have access to. Supposedly my kt-search client (for opensearch and elasticsearch) should work on an Apple watch. I've not gotten around to testing that just yet and I don't see why you'd want that. But it definitely builds for it. I had one person some time ago trying it out on IOS; same thing (I'm an Android user).

Ecosystems are important. But it's also important to not get too hung up on them. I say that as somebody that made the bet on Java when there was essentially no such thing as a Java ecosystem. It was all new. Kind of slow and wonky. And there were a lot of things that didn't quite work right. But it had lots of people working on fixing all of those things. And that's why it's so dominant now. People are more important than the status quo.

Sometimes you just have to cut loose from the past and not go with something safe but very boring like Delphi, Visual Basic, Perl, and several other things that were quite popular at the time and didn't quite make it. They're still around and there's a half decent library ecosystem even probably. But let's just say none of those things are obvious things to pick for somebody doing something new that was born this century.

Go as an ecosystem is definitely large enough at this point that I would label it as low risk. Same with Rust. Neither is going anywhere and there are plenty of well motivated people working on keeping all that going. Same with Java. All valid reasons for using any of those. But nothing is set in stone in this industry. A lot of things people were using in the nineties did not age well. And it will be the same in another 30 years. Most of those old people that will never change retire at some point. Java projects are pretty depressing to work on these days for me. Lots of grumpy old people my age. I've had a few of those in the last few years. Not my idea of fun. The language is one thing but the people haven't aged well.

philipwhiuk2• 1 year ago

Most of my new back-end code is actually Scala these days which I have a very love hate relationship with.

Kotlin. I don't have much experience with. I know it's fairly lightweight syntactically.

I'm unconvinced by cross-compile to web stuff so far. Scala.js looked very ugly.

codr76• 1 year ago

I'm pretty fond of Java; it's definitely a superior language to Go if you ask me, which I've also written a ton of code in.

But I stay away from Spring Boot, end the entire EE stack of crap that came before it, if at all possible.

I've had more success adding whatever I need on top of embedded Jetty.

It's mostly a cultural problem, no one is forcing you to go the AdapterFacadeInjectionBuilderWhatever way.

I've been working on a library to simplify interfacing with relational databases for a while now. With several implementations in Go and other languages. And the java version looks at least as nice as the rest to my eyes:

https://github.com/codr7/tyred-java

evantbyrne2• 1 year ago

I've written ORMs for both Java and Go and agree that Java is a wonderful language with a much more complete type system than Go. However, it feels like Java web development teams typically suffer from not having their own Wagtail/Payload/etc and build way too much from scratch. Maybe there is some great open source framework+CMS out there making waves in Java land that I'm unaware of?

brabel• 1 year ago

But Javas has so many of these web frameworks?!

* Spring (https://spring.io/)

* Spring Boot (https://spring.io/projects/spring-boot)

* Helidon (https://helidon.io/)

* Micronaut (https://micronaut.io/)

* Quarkus (https://quarkus.io/)

* JHipster (https://www.jhipster.tech/)

* Vaadin (https://vaadin.com/)

That's just to mention the bigger ones, there's lots of mini frameworks like Javalin (https://javalin.io/) and Dropwizard (https://www.dropwizard.io/en/stable/)...

There's even the previous generation of big app servers like Weblogic and JBoss.

It's just incredibly weird for me to see someone say Java is missing some sort of framework, it just has EVERY kind you can probably imagine.

rr8082• 1 year ago

The best thing about Go is no Spring framework. I like Java but finding Java projects without Spring is difficult.

jjav• 1 year ago

What is forcing the use of Spring?

I've been a frequent Java programmer since its earliest days (started around 1996) and I've yet to ever use Spring.

None of the bad parts of Java are actually a part of Java!

demi566• 1 year ago

But you see nobody really wants to be “different” if there are 100 people and the first 90 went right the probability of the remaining 10 going right will be higher. Java was designed to be business oriented and I think this is why Go and Java is very different not in terms of language but the way the community makes decisions

invalidname• 1 year ago

All k8s operators are written in Go. It's really unsurprising that Java doesn't fit there. Java has huge advantages for typical web applications (observability, deployment flexibility, deep toolchain beyond IDE etc.). I've seen companies trying to use Go in the environment where the JVM excels, then breaking down the problem to thousands of small microservices which end up making something simple into shards of complexity.

Java is a general purpose application development language. Go is a system language that isn't as deep as Rust. They are very different things and comparing them doesn't make any sense. Like the people comparing Rust to JavaScript, these are not interchangeable.

azaras• 1 year ago

There are operators written in Java and Rust.

claudex• 1 year ago

There are even operator written with Ansible

anta40• 1 year ago

> Of course, Java still has its strengths, and for certain projects, it remains a solid choice. But for cloud-native applications, Kubernetes tooling, and our self-hostable software distribution platform, Go just feels like the right tool for the job.

Yeah. I see Android app development is still mostly dominated by Java/Kotlin. Of course you can do it with Go, e.g: https://fyne.io. Never try to write something serious with it, just messing around with the examples.

newAccount2025• 1 year ago

In the course of a developer's years, if I only restart the server two times an hour, this saves me an additional day (!) of development time per year.

You are working too much.

user9999999999• 1 year ago

Any suggestions for how to store request scoped data without context? Specifically when using middlewares, like in the example of an auth middleware, needs store isAdmin or isLoggedIn or UserId

alpb• 1 year ago

Presumably you control the entire handler stack in Go. So you can extend the HandlerFunc signature with parameters customizations to carry explicit structs, or return “error”, for example.

time4tea• 1 year ago

The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

Just use new() it's pretty fast.

okeuro495• 1 year ago

But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware...

No, people use it because we don't want to reinvent the wheel.

Spring is well documented and Spring Boot gives you a set of dependencies that all work together.

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

anthropodie2• 1 year ago

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

It sounds good but in reality people end up spending time messing around with config files and annotations.

optician_owl2• 1 year ago

Spring Boot gives you a set of dependencies that all work together.

But spring boot deps is infamous meme.

Then you don't have to spend time messing around with things like OAuth and authentication

Yeah. The funny thing is reality is quite complicated and spring supports a lot of (almost) documented cases. But 99% javaspring developers do not care. I met quite a lot of experienced devs and only 2 of them know how to optimize application start or which errors Kafka wrapper would not retry and so on. Half of the non-default situations are solved via reinventing the wheel because of a lack of understanding of nuances. I can't say people are dumb, many of those devs are smart. I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources.

whstl4• 1 year ago

I don't see how writing "one more OAuth client" or "one more login thing" using Spring Boot is not reinventing the wheel in itself.

If you really care about "not reinventing the wheel" there are ready-made paid solutions such as Auth0 and Cognito, plus self-hostable open-source options like Keycloak, Authelia, and Dex.

Also, Spring Boot itself uses third-party libraries for OAuth and Authentication, like Ninbus, which people can drop-in in their non-Spring Java apps.

smrtinsert2• 1 year ago

Don't know why this is down voted its absolutely true. When our tech leadership reviewed the numbers we changed auth design without touching the application code base really. Saved a ton of work considering we have many microservices.

Spring rocks.

cies5• 1 year ago

I found String (Boot) a horror to work with. Annotation based devt with super weird errors. The great thing was that most errors where run into by many before me so could be solved by a simple web search/ Stack Overflow article.

To me being able to CTRL-click my way into the libraries is very important. Overuse of annotations (a.k.a. magic) breaks that. It is what monkey patching is for Ruby. The beginning of the downfall IHMO of an otherwise great language.

Luckily Kotlin's culture avoids this.

procaryote• 1 year ago

Yep.

Java is really good. Java developer culture is awful.

If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

cies5• 1 year ago

Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose.

It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

divan• 1 year ago

Java is really good. Java developer culture is awful.

First we shape our tools, then our tools shape us.

pjmlp6• 1 year ago

That is actually enterprise culture, using Go won't make a difference in the enterprise space.

Ever looked into Kubernetes source code?

okr• 1 year ago

Spring boot is just a tool. People seem to forget and take for granted the knowledge that is hidden there. Sure you can wire everything together yourself, but who does that? It would be such a waste of time. I rather wait these 5 seconds for a long running service, tbh.

mooreds• 1 year ago

At $CURJOB, we have built a pretty good business on an app built in Java. We don't use Spring, but instead a lightweight MVC of our own creation[0]. It is open source but I don't know if anyone else is using it :) .

I once asked the founders why they chose java; it was because it was 2015ish and they had an existing product in java and they knew it. Which makes sense to me. I think there's a lot of path dependence to language choice.

I also think the domain matters. For database based webapps, Java can be great. Lots of tooling and knowledge around it. And modern java is pretty friendly to write. Plus, if you are interacting with something over an API and deploying it via a container, who really cares what it is written in?

For kubernetes operators? Seems like a natural fit for golang. Anything kube really. I had a friend who ran a k8s consultancy for a while and said that they'd prototype stuff in python because it was easy, then implement in golang because that was what was consistent with the rest of the ecosystem.

0: https://github.com/prime-framework/prime-mvc

tombert5• 1 year ago

I have said that for awhile: the worst thing about Java is Java developers.

I have some issues with the Java language (though Java 21? Actually pretty ok!), but there's no question that there's a lot of great stuff in regards to libraries in Java land.

A lot of the stuff that's just built into the JDK is already very good, for example. NIO can be a bit hard to work with, but is generally very good, fast, and reliable. A lot of the concurrency abstractions (e.g. BlockingQueues) are really pleasant to work with for most concurrent programs, the different types of mutexes/locks give access to most of the patterns you want, and the thread-safe collections like ConcurrentHashMaps are very boring, in that they work pretty much exactly as I want them to.

If we extend to third party libraries, it's even better. Vert.x and Disruptor, for example, are downright excellent tools for wrangling concurrency.

The issue is that it feels like a lot of Java developers are stuck in 1999; it can be like pulling teeth to even use NIO, which isn't exactly "new" at this point. When I wrote some stuff using BlockingQueues instead of throwing `synchronized` everywhere, people acted like I was grabbing this was some exotic code from a distant land that had never been tried before, When I imported Vert.x into my project because I needed to run a lot of non-blocking concurrent tasks, it required a lot of justification for using it instead of using threads everywhere.

smusamashah• 1 year ago

At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have.

Someone shared a Job posting which asked for "no java experience". It was funny.

watt2• 1 year ago

If you write Java just like you would write Go - meaning, no reflection shenanigans, use Jigsaw to cut out unneeded JVM stuff, or use GraalVM and compile natively (which you will be able to, because you did not use any of JVM reflection magic), Java will absolutely be competitive.

theshrike79• 1 year ago

It's kinda understandable. I've seen "Java coders" write Python for example.

The first thing they do is create a class and maybe even a Factory or Interface.

You can see instantly where their experience is from and it's hard to unlearn.

dominicrose2• 1 year ago

I tried truffleruby for the adventofcode challenges. Almost everything ran faster with normal ruby. I got a stack too deep error in truffleruby that I didn't get in normal ruby. I don't recall having more problems with memory with one or the other. There was one case where truffleruby was really useful though.

Thus I'm with you that it's not a systems programming language. It seems good for processes that stay ON, like servers.

But then when compared with PHP, during development you don't need to worry about the server, it just takes the most recent version of your code. Surely hot-reload can be a solution with java, but in practice it's a complication, especially if you're part of a team/project where there is no hot-reload support.

HumanOstrich• 1 year ago

I don't follow. Seems like the issues you had were due to truffleruby and how it implements ruby's internals on the JVM.

That's not a Java/Kotlin/JVM issue.

gf00028• 1 year ago

Why would you expect any speedup for programs that run for a split of a second?

Twirrim2• 1 year ago

The JVM doesn't attempt to compile a method until a method has reached 10,000 executions. So it's extremely likely your code ran the entire time in interpreted mode. Even if a method did get flagged as hot, you've then got the time taken to do the actual compilation to native code to contend with.

If you're trying to write systems code and want to use the JVM, GraalVM can do full ahead-of-time compilation and will get you almost instant start up with all methods natively compiled.

unscaled5• 1 year ago

I think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims.

It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platform for writing an Kubernetes infra tool like operator or a sidecar (mostly due to heap size and more a complex binary packaging story), but using Spring Framework for writing these kind of tool is a bigger problem. If they just wrote their initial tool in Kotlin without using Spring framework at all, it would be much faster. They could even have kept Dependency Injection with a lightweight framework like Koin or Dagger (even a reflection-based framework like Guice performs worlds better than Spring).

I would probably still prefer Rust for writing most infrastructure projects nowadays. GraalVM Native Images has similar memory footprint to Go and solve the slightly troublesome JAR deployment story, but with the complex license terms for the enterprise edition (where most of the performance optimizations are), I don't feel safe using it. I also prefer Rust's concurrency model and I find cargo to be a far more pleasant experience than either Maven or Gradle, but in the end of the day, you will not see serious issues if you use Kotlin in a sane way, and you can even save on some Go boilerplate.

AYBABTME• 1 year ago

Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go.

I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.

indemnity• 1 year ago

Funnily enough the initial version of Kubernetes was written in Java! But refactored into Go early on https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

itsthecourier• 1 year ago

yeah, this author reminds me of the guys who think simpler is better because they haven't read the whole documentation on why the thing is complex in first place, do they end up reinventing the wheel badly as they start to grow and discover problems already solved in mature frameworks

the lack of specific mention of scenarios and features beyond dependency injection suggests ignorance IMHO

CharlieDigital14• 1 year ago

I find this very common when working with JS backends. Once you get serious, you end up replicating a lot of the complex concepts of frameworks like Spring or .NET

zerr• 1 year ago

Do you suggest to use vanilla Java instead of Spring?

renegade-otter• 1 year ago

https://notes.ericjiang.com/posts/751

"PayPal and Wal-Mart have also had high-profile switches to Node.js. Of course, they’re comparing two completely different things to make Node.js look better. In these too-good-to-be-true stories, they’re switching from a gigantic enterprisey codebase to a Node.js app written from scratch. Is there any question that it wouldn’t have been faster? They could have switched to pretty much any anything and gotten a performance gain.

In LinkedIn’s case, they had proxies running on Mongrel with a concurrency of 1. It’s like switching from using one finger to type on a QWERTY keyboard to using ten fingers on a Dvorak keyboard and giving all the credit to Dvorak for a better keyboard layout."

P.S.: Google became so awful that a search for even the direct title of the article does not land it in the top results - just references to it.

boreas7878• 1 year ago

Yep, he is comparing the most bloated enterprise framework to lean Go apps. This article is so wrong in confusing Java with their particular monster project. You can definitively AoT-compile in Java, there are modern lightweight frameworks like Javalin, and I think the language itself now allows to write web services without any library.

725686• 1 year ago

"cargo cult" really? Have you ever built maintained big a Java codebase? Spring is a marvel that sprang out of the experience of very, very talented people. It can be misused, of course, like any other technology, but it is a huge productivity booster.

cies5• 1 year ago

You are joking right?

"Spring is a marvel that sprang out of the experience of very, very talented people." --> sounds very culty to me.

And yes I maintain both Spring and non-Spring JVM projects.

coldtea• 1 year ago

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

I dunno, some databases and things like Lucene are written in Java.

jayd16• 1 year ago

Is it wrong that I judge anyone that calls DI "black magic"? Clearly it's just computers all the way down and even spring DI isn't that hard to follow.

It's one thing to call it bloated or annoying or tedious but why are we proud to announce we didn't do the work to figure it out?

psychoslave• 1 year ago

What do you call DI here?

Black Magic is doubly negative here, but I guess that it can fueled with the feeling that less automagic in a codebase helps downstream debug and moving to maintenance mode, as it increase the chance to let a quick grep reveals immediately where the associated code is.

kebsup• 1 year ago

I'd consider a lot of spring annotations "black magic" , because you can't simply go to definition and see how/what they do.

gf00028• 1 year ago

You... literally can? Yeah, you may have to grep for the annotation's name, but it's not like it's hidden/closed source/whatever.

marginalia_nu2• 1 year ago

Spring's annotations arguably are black magic, but while Spring offers DI, DI is not Spring, and honestly something like Guice is a lot easier to follow since it only does annotation-based DI and not a bunch of other stuff.

raffraffraff• 1 year ago

We even went so far as writing infrastructure code for Kubernetes clusters that automatically provision apps in Kotlin.

Dear god. Compared to the go code required to do the same thing, this is crazy.

Edit: I removed reference to terraform, seems like there's no infrastructure code here, it's helm + operator.

rzz3• 1 year ago

A coworker once claimed that Go is the new Java, and I haven’t really been able to refute it.

pjmlp6• 1 year ago

This looks like one of the typical "we switched from A to B, whithout actually mastering A, so B is alright" kind of posts.

Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX.

No mention of AOT compilers, JIT caches, and so forth.

linkdd• 1 year ago

And it's fine. Why continue using something you don't master?

Yes you could try to master it, but it takes years. If another tool compensates your lack of mastery, why not use it?

WJW2• 1 year ago

To me the implication is that the culture at this company won't allow this team to master Go either, and in a few years there will be a post describing how they moved from Go to another language.

Many people like to write about how Golang is so simple, but the drawback of that simplicity is that many features of other languages are either covered by additional dependencies or by inflating code size. It's just as possible for Go projects to devolve into big balls of mud as for any other language.

nprateem4• 1 year ago

Because like any shortsighted decision it can come back to bite you later.

lenkite6• 1 year ago

There are a lot of leanings to master for Go as well which they may have not discovered.

As an example, the Go runtime does not honor container resource limits. You would think this would be one of the very first fundamental features supported out of the box by an advertised "cloud native" language.

zipy1242• 1 year ago

I like to think of these problems as having skill ceilings and skill floors like in video games. For large companies often the skill floor is more important than the skill ceiling. If it is easier to start in B than A, even though after years of experience A can be much better, it might still be a better choice to use B.

When you have lots of junior devs, you are more concerned with this upstart time, and I think in this case for example, Java makes it very easy to write poor code, or use poor packages. Yes a master in Java can take advantage of the extremely mature ecosystem with tools like those you have mentioned, but for those who are not experienced like you, they may get better productivity out of what you see as the less powerfull tool.

ivan_gammel4• 1 year ago

I do have experience of managing junior teams and I think Java is actually great for them. You only need one senior person to kick off the project and put down the rails - a relatively small effort if you use frameworks instead of bespoke solutions. The team just needs to follow the lead. It is extremely cost efficient and good enough for business in terms of quality/security/performance.

kitd• 1 year ago

pprof data via HTTP is part of the Go stdlib and is pretty close, good enough for 95% of cases. One could argue you need those tools less in a Go codebase anyway ;)

AOT is mentioned and JIT is not relevant.

pjmlp6• 1 year ago

pprof isn't not even close to what Visual VM and Flight Recorder are capable of, hence why then there are stuff like open telemetry integration, which require active coding to provide sensible data.

This is the only mention of AOT

Java's JIT (Just-In-Time) compiler and Go's AOT (Ahead-Of-Time) compiler are definitely two very different approaches and therefore hard to compare.

Zero content on all the options since Excelsior JET and other commercial alternatives came to be, or the free beer alternatives available nowadays.

JIT caches and plain old JIT aren't the same.

JIT caches are similar in concept to AOT with PGO, with the difference that instead of doing that once for the lifetime of the executable with data from test runs, it gets updated after each production execution.

unscaled5• 1 year ago

I think most of the tools on the second line are not highly applicable to a Kubernetes operator, or otherwise would just use the "Cloud Native way of doing things".

Something like JRebel would generally be a big no-no for Kubernetes, where the container image of the operator is expected be immutable (at least in terms of the code running in there). It may or may not be okay for developing an operator, but that's certainly venturing into a bit of an unknown territory.

VM agents and JMX are usually replaced by explicitly adding Open Telemetry support and/or a Prometheus endpoint. It's certainly more boilerplate and manual work, but so many more things are explicit in Go, that's just something you've got to buy into. If you're using Rust or Typescript this could be a lot more automated but that's not the case for Go.

Advanced profiling is probably something you'd have to give up, but I doubt a Spring shop would be deeply into profiling. The low hanging fruit is to just throw away spring and get an immediate 200%-400% performance boost.

But the JVM is still a more mature platform. Throughput is better on the JVM than on Go and some things are very troublesome in Go (basically anything that requires code generation).

My personal "cool tool" that I can run on the JVM but doesn't have a mature equivalent in Go is PIT[1] for mutation testing. But not everybody will be using mutation testing, just like not everybody will be using JRebel or JMX. And it doesn't mean everybody should. If you're a Spring a shop the thing you'll be probably missing most in Go would be things like Dependency Injection, Java-like ORMs, reflection magic and Spring Configuration Server.

[1] https://github.com/hcoles/pitest

xxs3• 1 year ago

Pretty much. There are lots of post in that form, it makes for a good self tapping on the back and few blog posts - without any questions answered.

OTOH - if that's what makes run the business, I'd not argue.

llm_nerd• 1 year ago

Totally orthogonal, but it's also a super weird piece in that it starts by listing three authors, but then has several paragraphs giving a personal account of a single person's history, as if someone wrote their blog entry and then other people demanded a slice of the credit.

IshKebab• 1 year ago

I mean, they don't mention monitoring... so so why would they need to master it? How would mastering monitoring tools help them with the problem that Java startup time is orders of magnitude slower than with Go? Especially without having to do any extra configuration work.

Ygg2• 1 year ago

I'm not sure who said it, but the quote went something like this: Programmers are at fault for the current status in Computer Science, rather than working on expanding their knowledge they keep chasing the latest fad.

If someone knows which cankerous Computer Scientist said this, I'd appreciate a reply.

ninetyninenine• 1 year ago

God I hate working with Java developers on go projects. They try to introduce “design patterns” into the whole ecosystem and twist golang into doing something it wasn’t designed to do.

It’s a bit too late because tons of golang libraries are like this now.

wiseowise• 1 year ago

I wish this “DI black magic” meme would die. If you’re afraid of runtime DI, then use Dagger 2.

KronisLV• 1 year ago

Never really heard of Dagger before, but I love what I'm seeing: https://dagger.dev/

On the other hand, using DI with Spring is both powerful and really annoying when things blow up due to unsatisfied dependencies, I'd much rather see that at compile time, so Dagger seems right up my alley! Thanks for mentioning it!

TheSmoke• 1 year ago

I wonder how a migration to for example Micronaut from Spring would look like in their case. It is optimised for startup time, performs the dependency injection and annotation processing in compile time as well.

ed_blackburn• 1 year ago

The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you.

It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO.

You can still do inversion of control without an IoC container—instantiation works just fine! Look at Go’s HTTP middleware pattern with structural typing and first-class functions. No config files, no annotation magic, just composition, testability, and code small enough to hold in your head.

anthropodie2• 1 year ago

It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you.
No config files, no annotation magic, just composition, testability, and code small enough to hold in your head.

This. When I look at code I should just be able to follow it and know what's happening. The whole annotation magic and config files makes it hard to understand the flow of things.

never_inline2• 1 year ago

heavyweight ecosystem

Try micronaut once. It does DI and even ORM mapping (with micronaut data jdbc) at compile time and avoids most reflection.

aqueueaqueue2• 1 year ago

IoC isn't even DI. IoC is saying "I need to talk to a service that handles these account operations I care about" rather than "I need a MySql connection, a coupla s3 buckets and a folder on disk"

DI can support both the "I need" and "I orchistrate" patterns.

Obviously modulo leaky abstractions! You might want to known if that account code is in L1 cache or Timbuktu.

chamomeal2• 1 year ago

So is DI usually referring to automatic framework-wiring DI? Cause I constantly pass dependencies in as arguments and call it DI.

gf00028• 1 year ago

pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO

Ergo, more code, much more development time, more chance for bugs, for questionable benefits (there are an endless number of web applications running on Django. If python is fast enough to tell the OS what IO to do, then surely enough Java with two indirect calls (which you will likely end up doing in your hand-written implementation as well) will be more than adequate.

Also, I don't buy that more code is easier to hold in one's head. An annotation that literally declaratively says what that thing is is much easier to grasp and maintain.

thecupisblue• 1 year ago

I wouldn't see this as the win for the team. The real win here would be:

* Understanding where the issues and bottlenecks are coming from * Understanding how it came to these issues * Figuring out how to resolve the issues without changing the whole tech stack

That way, the team would end up with a deeper understanding of their organisational issues leading to it, understanding of their code, cost of services, cost of the ecosystem and cost of computation. They would have been able to apply this knowledge to other projects in the company running the same stack.

The way this is written is basically sweeping the problems under the carpet with "tech slow, new tech fast" solution, while simultaneously letting the team keep doing whatever it is they were doing that made this slow. This is nothing but a surface level rewrite without understanding the real cause of the pain.

hyperpape• 1 year ago

the JVM all but forces on you

I don't think you're wrong, but you're making this sound like it an issue with the JVM. It's certainly not. I guess it could be an issue with the Java language, but I don't really think so.

Mostly it's an issue with the Java ecosystem.

chamomeal2• 1 year ago

Yeah sounds more like a java issue to me. Clojure is usually beautifully terse and straight-to-business with very little boilerplate, and it usually runs on the jvm.

But still agree with the other commenter on the benefits of go. I’m not a huge fan of go, but it’s definitely encourages grug brain style (https://grugbrain.dev/) which has many benefits.

In fact, the only time I disagree with grug style is when I’m really close to the perfect generics for a TS function with lots of coupled inputs. Always so close…

DeathArrow2• 1 year ago

I am sure Go has many benefits, but coming from .NET I don't see a big improvement in switching to Go.

.NET feels less verbose, it's batteries included, has an AOT compiler, tons of libraries, starts fast, has very good tooling and performance wise it compares well to Go. Also, it can be used for more than web apps and command line tools.

Where I see a benefit, though, is using go in a large greenfield project because Go is very easy to learn and you can attract Java, .NET, Python, Javascript and even C and C++ developers so you can assemble a team fast.

Though in a microservice context it might not be a large benefit.

mickael-kerjean• 1 year ago

The big change is cultural. The places I've seen using .NET felt like cults to me, a monoculture were everyone must run windows, swearing by how powershell is the shell of the gods, ms sql being the only true data store that's the best solution for 100% of every use cases, azure being the best cloud provider, and everyone forced to use vs code because of all its fancy integration with even the pm tools.

neonsunset4• 1 year ago

What are the mythical .NET cults which swear by Windows, PowerShell and MSSQL you speak of? Every other ".NET shop" I know nowadays deploys to Linux hosts/container images hosted wherever and develops on a variety of systems where the OS of choice has become mostly a non-factor.

DeathArrow2• 1 year ago

Depending on how Java application was devoped, the real benefit might be breaking free from the kingdom of nouns, land of design patterns, country of OOP.

pshirshov• 1 year ago

1) There is a perfectly working AOT compiler for JVM, namely Graal Native. Sub-second startup times are easily achieavble. 2) Dependency Injection does not require run-time reflection, I made one reflectionless DI for Scala and one for C# 3) Spring is not the best DI in the Java ecosystem

watt2• 1 year ago

Dagger will give you DI at compile time (build time), via annotation processor feature. (And it seems Quarkus can do it as well?)

zwnow• 1 year ago

There's one simple argument to never touch Java: FactoryFactory produce ArgumentFactory, ArgumentFactory.builder().build(argument)

darkhorse222• 1 year ago

I have never been able to rid myself of my earlier career instincts that people who spend time debating the pros and cons of languages are not really builders. I am a computer engineer, I have very little respect for coding languages since ultimately they always come down to the same fundamental computing mechanisms: processors and memory.

Perhaps when efficiency is needed I can understand. But most of the time seeking efficiency is yet another non-builder priority. I have always found efficiency comes from good thought, not good tooling.

Mekoloto• 1 year ago

This doesn't give me any clue how it would really feel like to switch a big webapp/enterprise webapp from Java to Go.

How is the handling of database and entities? How is the security model and support for api endpoints?

etc.

I have had very little issue with java startup time. Hot code replacement exists for decades

DrScientist• 1 year ago

Never quite understood the attraction of dependency injection frameworks.

Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so?

Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime?

Just seems as a very complicated way to avoid creating package c that brings together package a and dependency b in a simple class that creates b and passes it into a.

What am I missing?

HexDecOctBin• 1 year ago

What am I missing?

Job Security.

mrkeen3• 1 year ago

I second this.

The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible.

That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc.

20 years ago, DI meant that your TaxCalculator didn't know about your database.

Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.

wink• 1 year ago

Never quite understood the attraction of dependency injection frameworks.

Many years ago there was a running joke that a "dependency injection framework" in PHP was a single array with stuff in it.

Then it all became much more java-like.

tored• 1 year ago

Dependency injection containers can be overly complex and allow complex configurations, too much magic.

That is why I kept my container library simple, you read thru all the source in less than 15 minutes.

What I like about it is that it is natural to use composition with classes, it encourages to create classes to divide your application into reusable parts.

And with my library all you do is to put the dependent class in the constructor. My library can without much effort be replaced with normal factory, that is by design.

Warning PHP https://github.com/paketphp/bero

staticelf2• 1 year ago

I work at a company that is based on a large java application. The main app takes around 20-30 seconds to startup and while it probably does a lot of stupid shit that have accumulated over the years I believe this is more common in javaland.

The culture around java is kind of enterprise, do everything unnecessary complex with strange patterns you've never heard of etc etc which makes the everything unnecessary slow and complex. Where as other languages like node or go small libraries is the culture so it's not weird that it is what it is. I have many times suggested to use simpler tools or frameworks like Javalin but to no avail. Java devs love their spring.

Instead of just doing the thing you want to to, with java devs, you have to follow pattern that makes you create a several classes and interfaces when in reality it could be a couple of lines.

switch007• 1 year ago

20-30s sadly isn't even that terrible

staticelf2• 1 year ago

I'm guessing you're probably right which makes me kind of wonder how java devs get any work done at all.

cs02rm0• 1 year ago

I really liked Dropwizard. It had a philosophy of picking a set of tools that could help people get up and running with a java web application quickly and that would serve them well for a long time, choosing the best tool for the job.

Then Spring boot came along where they defaulted to the much fatter Tomcat, apparently just to be different, and then went down the list of libraries and instead of picking the best one, they picked the Spring one.

I never understood that philosophy, but it won out. It looked at lot to me like no one ever got fired for choosing IBM/Microsoft. But it was so much worse. Other frameworks have improved on what Dropwizard offered for startup times, etc. but still don't seem to have gained the traction to unsettle Spring.

anthonybsd• 1 year ago

Larger than 2GB RAM JVM containers? It sounds like the author didn't really explore any of modern container-ready frameworks and blamed the ecosystem. Move from Spring Boot -> Micronaut or Quarkus and compile your code into into GraalVM image and you get sub-100MB containers.

mrbonner• 1 year ago

Start up time of the JVM is 8s? I would definitely say that it depends on how their service initialization work. I have seen service accesses database to warm cache, calling other services to initialize their configuration, or simply reading config files before fully serving. And all that take time! There is no way against that regardless of your PL or runtime.

A typical no network initialized service in Java would start under 500ms (a p90, give or take).

monksy2• 1 year ago

There are some arguements that were made in this post that don't matter at all.

One of those is: Cold start time

This isn't a big deal in the context of a web app. 8s vs 100ms. If you're scaling up a service. 8s is not a big deal in the scope of fixing a horizontal scaling issue.

Additionally, what it's considers bloat: Yes, you should optmize your app. It depends on the context of your application. Brining up a rest app that needs to stay up..who cares if it takes .5-1gb of ram.

Also, I didn't see it pointed out about the concerns of the lack of 3rd party frameworks. I find this disjointed and sparse frameworks to be more of a concern for a language/ecosystem than what the author pointed out.

One year after switching from Java to Go

Related Stories