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

371–380 of 503 posts

Re: One year after switching from Java to Go

#371

Post by pjmlp »

hu3 wrote: post #361
gf000 wrote: post #302

Earlier quoted context omitted.

Search within your IDE, do a Google search, whatever suits you. What mentality? And the cognitive load is to RTFM, so that you understand what are you doing. If that leaves any questions you can attempt to do a deep dive. It's not particularly high cognitive load to know that @GET is a get rest endpoint. How is that different without annotations? Documentation is also your best bet at first in case of a normal librar…

This is 2025. If you can't jump to your own code implementation without having to search for strings, your tech sucks. And most of your message doesn't even apply. How would I Google or read the manual for my own code? We're talking about different things it seems.

With a 1980's technology out of Xerox PARC, it is called IDE.

Re: One year after switching from Java to Go

#372

Post by chamomeal »

hyperpape wrote: post #355
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…

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

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…

Re: One year after switching from Java to Go

#373

Post by ivan_gammel »

zipy124 wrote: post #262
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.

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…

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.

Re: One year after switching from Java to Go

#374

Post by gf000 »

Mawr wrote: post #346
gf000 wrote: post #279

Earlier quoted context omitted.

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.

You can abort via panic(), but that is expected to crash the application, which is perfectly fine. It's the act of attempting to catch the abort that is fraught with problems. While in Go that is rare, in languages with exceptions it's normal and expected. Ignoring an error condition is possible in Go, but so unlikely that it's not practical to worry about it. As an aside, not that it matters, but logging an error is…

Logging can be a valid handling of error.

I just don't believe that most errors can be handled locally so besides returning an error (bubbling up), not much can be done. Go makes this part of the happy path, so neither can be easily seen/reasoned about anymore.

Exceptions do auto bubbling up, while languages with ADTs have more strictness than go, and often have some syntactic sugar/macro to help with the common case of returning the error (rust's ?).

Re: One year after switching from Java to Go

#375

Post by gorjusborg »

Twirrim wrote: post #369
kuschku wrote: post #332

Earlier quoted context omitted.

Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

People can write bad code in any language

It is almost like language is a conduit for something, I wonder what though. I will have to think on it.

Re: One year after switching from Java to Go

#376

Post by Twirrim »

dominicrose wrote: post #248
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…

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, li…

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.

Re: One year after switching from Java to Go

#377

Post by chamomeal »

aqueueaqueue wrote: post #227
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…

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.

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

Re: One year after switching from Java to Go

#378

Post by throw-the-towel »

pjmlp wrote: post #318
procaryote wrote: post #213

Earlier quoted context omitted.

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

That is actually enterprise culture, using Go won't make a difference in the enterprise space. Ever looked into Kubernetes source code?

At a former job, my coworkers successfully wrote Java in Python.

Re: One year after switching from Java to Go

#379

Post by gorjusborg »

nprateem wrote: post #266
okeuro49 wrote: post #250

Earlier quoted context omitted.

> I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources. You can use as much of Spring or as little as you want. Don't want Hibernate? Use JDBC template. I have noticed that people who don't use a framework, just end up inventing their own bespoke framework, which unlike Spring, is not documented and has no help available online.

It's a paradox as old as time itself. Otherwise intelligent devs assume they can do a better job without all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort. It's either stupidity or arrogance.

Why not both?

The trouble now it is that Spring Boot allows getting things up and running without having to know anything about what is underneath.

That is great, until you have to change the way it behaves.

Re: One year after switching from Java to Go

#380

Post by demi56 »

lenkite wrote: post #351
demi56 wrote: post #345

Earlier quoted context omitted.

> As an example, the Go runtime does not honor container resource limits That’s no longer true for Go 1.19+

AFAIK, the basic issue is still open at https://github.com/golang/go/issues/33803 and https://github.com/golang/go/issues/59715 . You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs . Go 1.19 only had this in its notes for memory changes "...includes support for a soft memory limit. This memory limit includes the Go heap and all other me…

> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"

Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles

> You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.

I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue

> Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...

We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19

Post reply on HN