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

381–390 of 503 posts

Re: One year after switching from Java to Go

#381

Post by gf000 »

btreecat wrote: post #364
lenkite wrote: post #351

Earlier quoted context omitted.

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…

Most Jvm shops/devs I know are still on 11

Upgrading from 11 is trivial though and we are at almost 24. The hardest was 8->9, or 9->11.

Re: One year after switching from Java to Go

#382

Post by ReflectedImage »

WJW wrote: post #240
linkdd wrote: post #194

Earlier quoted context omitted.

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

Golang's standard library looks pretty complete to me and they will probably master it in a month.

Re: One year after switching from Java to Go

#383

Post by [deleted] »

procaryote wrote: post #213
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…

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

[deleted]

Re: One year after switching from Java to Go

#384

Post by boreas7878 »

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…

Yep, he is comparing the most bloated enterprise framework to lean Go apps. This article is so wrong in confusing Java with their particular monster project. You can definitively AoT-compile in Java, there are modern lightweight frameworks like Javalin, and I think the language itself now allows to write web services without any library.

Re: One year after switching from Java to Go

#385

Post by gf000 »

Cthulhu_ wrote: post #341
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…

> Then wrap the error as many times as you want to annotate additional lines as the error is handled up to the top level I'd add that this is a last resort; errors should be handled and resolved as close to where they occur as possible. Having them bubble up to a central error handler implies you don't really want to do anything with it.

I would argue that in the majority of the cases that's the only reasonable behavior. I do agree that errors should be handled as close as possible to where they occured, but not any closer -- e.g. there is not much you can do within a library's functions if an unexpected error occured inside. It should be handled at whatever business code happens to call it. And in the worst case, they should bubble up to a central handler, that either outputs an 500 error, or an error dialog.

Exceptions pretty much make this the sane/default behavior, with rust-like ADTs with syntax sugar being close.

Re: One year after switching from Java to Go

#386

Post by FrustratedMonky »

gf000 wrote: post #354
FrustratedMonky wrote: post #349

Earlier quoted context omitted.

"Annotations are declerative shorthands." OR. Are annotations a crutch for something that should be in the language. Just generally, if some tool has to use annotations, then that is indicator of something that should be in the language.

So which language has native REST endpoints? Session-aware security? Like, this is just standard metaprogramming, if you don't have it you will just reach for dumber tools like non-language aided code generation.

all right, maybe it is a spectrum.

On other end

Type annotations in JavaScript. Just use a language with Types.

Re: One year after switching from Java to Go

#387

Post by staticelf »

switch007 wrote: post #331
staticelf wrote: post #288

I work at a company that is based on a large java application. The main app takes around 20-30 seconds to startup and while it probably does a lot of stupid shit that have accumulated over the years I believe this is more common in javaland. The culture around java is kind of enterprise, do everything unnecessary complex with strange patterns you've never heard of etc etc which makes the everything unnecessary slow a…

20-30s sadly isn't even that terrible

I'm guessing you're probably right which makes me kind of wonder how java devs get any work done at all.

Re: One year after switching from Java to Go

#388

Post by marginalia_nu »

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.

Spring's annotations arguably are black magic, but while Spring offers DI, DI is not Spring, and honestly something like Guice is a lot easier to follow since it only does annotation-based DI and not a bunch of other stuff.

Re: One year after switching from Java to Go

#389

Post by CharlieDigital »

Mawr wrote: post #338
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…

How can you "let the exception bubble up" when you don't know what "the exception" is nor where it's going to be thrown? The agency you imply here does not exist. All you can do is what you've described - catch all exceptions at the top level and log them. It's a valid strategy so long as you don't mind your service going down at 3am because someone didn't realize that the call to Foo() on line 5593 could in fact thr…

Nothing in languages that use exceptions prevent you for catching the generic exception type and handling it if you can recover/clean up. As I stated, my own rule of thumb (point (d) above) with respect to handling exceptions is "when I can/need to do something". If I can't do anything, then just bubble it up and log.

Case in point is accessing a remote REST endpoint where I might be throttled or the service might be down. I can do something (retry) so I'll write code that probably looks similar to Go with Err:

    var retries = 0;

    do {
      try {
        result = await makeServiceCall();
      } catch {
        if (retries == 3) throw;
        retries++;
        await Task.Delay(retries * 1000);
      }
    } while (retries
The exception bubbling mechanism just makes it optional so you determine when you want to stop the bubbling.

Re: One year after switching from Java to Go

#390

Post by AYBABTME »

unscaled wrote: post #290
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 think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims. It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platf…

Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go.

I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.

Post reply on HN