Hacker News Reader

Comment by sandGorgon | Hacker News Reader

I have a question for those of you who have worked on java..or considered working on java ..and ultimately did golang or something.

what would make you choose java :

1. is it a better framework than spring boot

2. is it a better tooling like heroku or something for java

3. is it better community & programming paradigms ? I once asked a question "can i write a java api using all variables as public" and got flamed pretty badly. Do people want an alternative to the MVC/DAO/DTO structure ...where the community doesnt flame them ?

4. is it something else ?

Because based on docker pulls, java still is probably just as popular as nodejs or something.

what would make java sexy again ?

View on HN

I'm excited about value types.

I'm less than enthused by the spring ecosystem. It does help you start quicker than you would without it but while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too.

Java as a language is fine and I have no real complaints there.

>while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too.

can you elaborate on this ? really have been considering spring boot, etc. But coming from the python world ...i feel it cognitively very hard to get through. But im super keen to know what issues come in production.

Most of us were under the impression that Spring in production just works.

>so I suppose a better framework would excite me too

especially from this perspective. What would you want ?

My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework.

We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors.

When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.

I should mention that this isn't the fault of dependency injection itself. It's the natural result of doing that dependency injection at runtime using reflection. A better way is to use code generation so that you can actually see and reason about the code when something goes wrong.

I don't choose Java but I work with it and I mind it less and less.

1. is it a better framework than spring boot

Dropwizard has a refreshing approach.

2. is it a better tooling like heroku or something for java

Working with kubernetes is seamless. Lots of ready made hooks to your JVM and your application

There is a strong push toward immutable everything and final all variables. It's ugly like often with java, but it's attainable by settings the linter to the max and adding yet another annotation ( to the package folder itself, and it's not enforced by the compiler unless you ask for it... )

4. is it something else ?

At this point I can crank out things fast in functional & immutable manner. Tests write themselves. JVM is rock solid.

It’s as sexy as it gets, even as it is. It has one of the biggest ecosystems, has insanely good performance, the best GCs, very good debugging capabilities, best dev tools, and that’s just the present.

It already has loom in preview which will make the whole previous thing suddenly non-blocking (this is uniquely possible with java due to the ecosystem being 99.9+% purely java, no FFI).

Once value types arrive, I will honestly see no niche other than embedded/lower-level not served by this platform. Oh, and there is of course Graal which will bring all these capabilities to even polyglot code bases, you can just execute some python script on basically java objects with java’s speed!

interesting perspective. Is there nothing you would want better ? at a fraamework level, not language.

just curious - i have heard comments of people looking for a simpler framework. And especially cloud integration/deployment.

I would prefer better integration of modern java features into frameworks. Pretty much ditch data POJOs for records, things like that. It is a bit harder to do for JPA entries as they are not just data, so they would likely need a wrapper, but the result of an sql query is a “record”, literally.

We (a team that has extensively used JVM before) went with Go primarily for the GC characteristics and WASM support. GraalVM was promising but seemed like it had a way to go when we prototyped on it.

I do miss the nice IntellIJ java features.

really ? even with ZGC ?

The GCs on the JVM are superior to what golang offers. You have several to choose from based on the use case you have (batch processing, web backend, latency sensitive ,etc.).

With a small team, the idea of having different jvm settings per service was daunting as we so far have found Go to work well for all use cases.

We also needed fast start times and hopefully graal continues to mature. We also worried about graal costs given oracles history.

The community edition is free and has a GNU license.

In my experience, you only need to start looking at GC parameters once you hit a certain scale. For the majority of services you'll be writing, especially in a small team, you don't have to worry about them. G1GC is really good, and if you need low latency, you have ZGC and Shenandoah.

We've seen the hoops that people had to jump through to get golang GC to work properly once they hit a certain scale.

The main reason we chose Go was compilation speed since our product would need to quickly compile and generate something that is fast to startup, and Graal was just too slow when we prototyped things.

The GC benchmarks we did showed that Go would work as well, so we begrudgingly moved to it.

Your team required a worse GC?

IMHO the problem with Java/Springboot compared to a Go or Ruby/Rails or JS/Node etc is the paradox of choice. For 99% of applications it doesn't really matter DB or html templating or background jobs or whatever you use. You want to use whatever everyone else is using for long term support and ease of hiring/onboarding.

what do u mean here ? the JVM ecosystem has more choice here ?

i thought the JS ecosystem was crazy full of packages.

At the package level yes but NPM, Node, Express, etc. are the dominant choices in the JS serverside world.

Reply on news.ycombinator.com