Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

Post reply on HN
Print view View original

321–330 of 503 posts

Re: One year after switching from Java to Go

#321

Post by pylua »

conwaytwitty wrote: post #310
pylua wrote: post #66

Earlier quoted context omitted.

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…

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…

I’ll have to look into burst cpu usage. Thanks

Re: One year after switching from Java to Go

#322

Post by pylua »

gf000 wrote: post #273
rahen wrote: post #217

Earlier quoted context omitted.

Cold latency is an issue with microservices. If you need to use Java, you'll likely end up using frameworks like Spring or Quarkus, which somewhat diminish the advantages of using the JVM and Java as a language. At that point, you might as well start with Go from the beginning.

Is it really an actual issue? How often do you restart instances or scale up horizontally? A cheap 10 years old desktop PC can easily handle all the traffic a medium-sized website generates at all times.

What do you define as medium size?

Re: One year after switching from Java to Go

#323

Post by jillesvangurp »

philipwhiuk wrote: post #298
jillesvangurp wrote: post #162

Earlier quoted context omitted.

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 trick…

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.

I never had much experience with scala.js. The nice thing with kotlin-js is that it's just kotlin. Thanks to Android, it's actually a good fit for UI development and a lot of the same libraries work in a browser as well. For example, we use koin for dependency injection, kotlinx serialization, ktor-client, coroutines, and a bunch of other stuff. We also use some npms. Stuff like maplibre and tailwind for example.

As for the compiled code. I spend about as much time looking at generated js as I do examining jvm byte code (none in case you were wondering). It's a compilation target. Yes it's ugly. But who cares? It actually goes through a mininification/uglification step as part of the webpack build. So, yes, it's going to be ugly.

Re: One year after switching from Java to Go

#324

Post by okeuro49 »

whstl wrote: post #255
gf000 wrote: post #252

Earlier quoted context omitted.

Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

> Like, what other option is there? For this specific case there's plenty... You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. You can use other frameworks that also have those features, in Java or in other languages. You can use a paid authentication services. You can use an open source authentication services.

> You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little.

Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.

Re: One year after switching from Java to Go

#325

Post by lenkite »

gf000 wrote: post #252
anthropodie wrote: post #212

Earlier quoted context omitted.

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

Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own.

In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc.

The extreme difference in basic developer culture causes visible differences in performance outcomes. Can't even blame the JVM - it is a superb beast that is overloaded by Java developers putting Mount Everest atop it.

Re: One year after switching from Java to Go

#326

Post by fweimer »

gf000 wrote: post #263
fweimer wrote: post #259

Earlier quoted context omitted.

JVMTI allows method patching: https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.h... The capabilities are somewhat limited, and an enhancement JEP was withdrawn: https://openjdk.org/jeps/159 On the other other, there is a movement to remove such late binding/rebinding features from the Java platform. However, I think JVMTI is expected to remain supported if the agents are loaded ahead of time. Only on-demand…

I wouldn't say that there is a movement to remove such late binding features -- the "movement's" primary goal is simply to properly encapsulate and mark any such part of the code (e.g. make it explicit in the module that that should be supported). That way AOT compilation becomes possible/efficient and dependencies can't hack into other packages in an unmaintainable way without explicit permission from the user, so t…

As far as I know, there is no tooling support to propagate these marks to the launcher program even in cases where they can be statically discovered. (This could be similar how dynamic linker agents (audit modules) are handled by the Solaris linker, via DT_AUDIT and DT_DEPAUDIT markers.) Mainly because OpenJDK does not provide a tool (beyond jar) that creates launchers.

This doesn't concern features that have been traditionally abused (such as reflection on core OpenJDK classes), but also harmless (from an encapsulation perspective) uses of JNI, and access to future features such as FFI/Panama. Justification for restricting those as well is not so much OpenJDK updates, I think, but that it could cause crashes that might be blamed on OpenJDK.

Re: One year after switching from Java to Go

#327

Post by gf000 »

pylua wrote: post #322
gf000 wrote: post #273

Earlier quoted context omitted.

Is it really an actual issue? How often do you restart instances or scale up horizontally? A cheap 10 years old desktop PC can easily handle all the traffic a medium-sized website generates at all times.

What do you define as medium size?

Stackoverflow famously ran on a single, although quite beefy server PC for a long time (not any longer, but not for performance reasons AFAIK).

I think it's a good data point to have to scale your workload to stackoverflow's, and reconsider the hardware costs.

(Obviously horizontal scaling has its place, but if it's that variably scalable, maybe there are better solutions, e.g. a single bigger instance -- often times even for cheaper)

Re: One year after switching from Java to Go

#328

Post by gf000 »

pylua wrote: post #319
gf000 wrote: post #272

Earlier quoted context omitted.

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…

In my game loop I was using optional. When I profiled it the use of optional was one of the slowest points that could be optimized using null checks and ifs. There were a lot of other slow areas as well, not where you would expect it.

Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.

Re: One year after switching from Java to Go

#329

Post by bdhcuidbebe »

amazingamazing wrote: post #67
bdhcuidbebe wrote: post #62

Earlier quoted context omitted.

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

Please do tell, what typescript, node and a few dependencies cannot do here.

Provide strong typing, low memory footprint and good performance at scale. See the topic of discussion for more details.

Re: One year after switching from Java to Go

#330

Post by pylua »

gf000 wrote: post #328
pylua wrote: post #319

Earlier quoted context omitted.

In my game loop I was using optional. When I profiled it the use of optional was one of the slowest points that could be optimized using null checks and ifs. There were a lot of other slow areas as well, not where you would expect it.

Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.

That’s the pain point - well written java code may not be the most performant depending on the situation.

It wasn’t just optional but other areas as well.

Post reply on HN