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

271–280 of 503 posts

Re: One year after switching from Java to Go

#271

Post by mrkeen »

DrScientist wrote: post #253

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

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.

Re: One year after switching from Java to Go

#272

Post by gf000 »

pylua wrote: post #66
philipwhiuk wrote: post #61

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…

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…

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

Re: One year after switching from Java to Go

#273

Post by gf000 »

rahen wrote: post #217
cmrdporcupine wrote: post #90

Earlier quoted context omitted.

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.

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.

Re: One year after switching from Java to Go

#274

Post by kebsup »

jayd16 wrote: post #160

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?

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

Re: One year after switching from Java to Go

#276

Post by kitd »

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.

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.

Re: One year after switching from Java to Go

#277

Post by gf000 »

ed_blackburn wrote: post #205

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

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

Re: One year after switching from Java to Go

#278

Post by ratorx »

throwaway2037 wrote: post #111
ratorx wrote: post #71

Earlier quoted context omitted.

In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example. Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY i…

> Most of my code will annotate a lower error with the context of the operation that was happening. This is easy to solve with chained exceptions to add context. > it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. You cannot add method args to an exception message? I am confused.

It is definitely possible with exceptions, but it is not the norm (you can do it yourself, but will a library also do it?) because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing.

And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions.

In practice, I’ve found that when I write Go, I end up annotating most error returns, so the benefit of exceptions for me would be minimal.

Re: One year after switching from Java to Go

#279

Post by gf000 »

kgeist wrote: post #216
CharlieDigital wrote: post #60

Earlier quoted context omitted.

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

Having exceptions means that every line in your function is a potential exit point, often without you being aware of it. This can lead to bugs when a non-atomic operation is abruptly terminated, and you might not realize it just by glancing at the code. When we were rewriting some code from PHP to Go, I remember that simply thinking about "what to do with err" led me to realize we had a ticking time bomb - one that c…

Go can abort at any point as well.

Also, ignoring an error condition (by either forgetting about it, or simply doing the nice and tidy if err dance with no real error handling in place, just a log or whatever) is much worse and can lead to silent data corruption.

Re: One year after switching from Java to Go

#280

Post by gf000 »

kebsup wrote: post #274
jayd16 wrote: post #160

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?

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

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.
Post reply on HN