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

231–240 of 503 posts

Re: One year after switching from Java to Go

#231

Post by cryptos »

RussianCow wrote: post #204
_w1tm wrote: post #191

Earlier quoted context omitted.

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

If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.

But that "framework" could be a simple factory function.

Re: One year after switching from Java to Go

#232

Post by mavelikara »

nesarkvechnep wrote: post #149
MrDarcy wrote: post #25

Earlier quoted context omitted.

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

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.

This isn’t anything special about Java. A determined programmer can write Fortran in any language.

Re: One year after switching from Java to Go

#234

Post by neonsunset »

PhilipRoman wrote: post #228
re-thc wrote: post #128

Earlier quoted context omitted.

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

Despite all the advances in JIT, I've literally never seen it correctly optimize a HashMap (happy to be proven wrong). Hopefully the renewed focus on value types can finally bring some sanity.

In C#, all struct generics are monomorphized and struct-based abstractions are zero-cost :)

Re: One year after switching from Java to Go

#235

Post by smusamashah »

time4tea wrote: post #156

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…

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.

Re: One year after switching from Java to Go

#236

Post by tugberkk »

cmrdporcupine wrote: post #90
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…

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.

why the downvote on this? is it wrong?

Re: One year after switching from Java to Go

#237

Post by KronisLV »

wiseowise wrote: post #198

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

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!

Re: One year after switching from Java to Go

#240

Post by WJW »

linkdd wrote: post #194
pjmlp wrote: post #169

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.

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?

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.

Post reply on HN