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

351–360 of 503 posts

Re: One year after switching from Java to Go

#351

Post by lenkite »

demi56 wrote: post #345
lenkite wrote: post #334

Earlier quoted context omitted.

There are a lot of leanings to master for Go as well which they may have not discovered. As an example, the Go runtime does not honor container resource limits. You would think this would be one of the very first fundamental features supported out of the box by an advertised "cloud native" language.

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

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

Re: One year after switching from Java to Go

#352

Post by gf000 »

lenkite wrote: post #344
okeuro49 wrote: post #333

Earlier quoted context omitted.

> In Java, people will pull in a 300MB+ mega-framework for a hello-world REST service. Oh and another 200MB for ORM. Another 250MB+ for nailpolish, etc. I just now used https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate). It generated a JAR that is 52MB.

Thanks - I haven't used the Spring Generator for several years now. However, I think one also needs to include the drivers, oauth stuff, template libraries, etc to get an accurate represention of "standard Java enterprise size". Gonna play with this offline and see how good it has got.

You might want to check the native spring native plugin as well, which can AOT compile the whole thing to a single binary (thanks to Graal).

Re: One year after switching from Java to Go

#353

Post by mattgreenrocks »

re-thc wrote: post #126
bdangubic wrote: post #86

Earlier quoted context omitted.

went to springone conference in vegas in 2016. eight years later, there are still no good alternatives :)

> eight years later, there are still no good alternatives Micronaut? Quarkus? Depends on what you need.

Quarkus seems pretty good overall. No real issues with it.

Still more config than I'd like but that comes down to the fact it is more for services than MPA webapps.

Re: One year after switching from Java to Go

#354

Post by gf000 »

FrustratedMonky wrote: post #349
gf000 wrote: post #284

Earlier quoted context omitted.

You do realize that Java is objectively less verbose than Go? Even on a vanilla language to vanilla language basis, but let alone against something like Spring Boot that does almost everything for you in a typical CRUD application. Annotations are declerative shorthands . How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose? What about a single SQL query…

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

Re: One year after switching from Java to Go

#355

Post by hyperpape »

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.

Re: One year after switching from Java to Go

#356

Post by spicyusername »

lelanthran wrote: post #146
throwaway2037 wrote: post #100

Earlier quoted context omitted.

> The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing This is not possible in Java or C#? Both of those languages are so simple to grasp.

> This is not possible in Java or C#? Both of those languages are so simple to grasp. Not really, no. Apart from the cognitive burden of knowing the test framework in use, the DI tooling in use, the Mocking framework in use, plus all the annotations that each framework may want/need, almost none of which applies to the Go projects I've seen, the languages themselves have drifted away from simplicity. I used to progra…

Gotta disagree for C#.

It definitely has more language features than Go, but by no means is indecipherable.

I find C# syntax to be quite crisp.

Re: One year after switching from Java to Go

#357

Post by Mawr »

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.

If it's easy then why does nobody do it? ;)

In all exception-based languages I know of, catching an exception is so syntactically heavy that annotating intermediate exceptions is never done:

    try {
        Foo()
    } catch (err) {
        throw new Exception("message", err)
    }
One line just turned into four and the call to Foo() is in a nested scope now, ew. At that point even Go is more ergonomic and less verbose:

    err := Foo()
    if err != nil {
        return fmt.Errorf("dfjsdlfkd %w", err)
    }

Re: One year after switching from Java to Go

#358

Post by the_gipsy »

roncesvalles wrote: post #171
bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

> Test using monkey-patching.

Can you elaborate? What library do you use?

Re: One year after switching from Java to Go

#359

Post by zero_shift »

MrDarcy wrote: post #25
bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

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…

> Regarding stack traces, it turns out you don’t need them. I strongly suggest a top level error handler in Go combined with a custom error struct that records the file and line the error was first seen in your code. Then wrap the error as many times as you want

So instead of a stacktrace, you are - tracing the stack? Am I understanding correctly?

Because it just sounds like a manual version of stacktraces

Re: One year after switching from Java to Go

#360

Post by mattgreenrocks »

WuxiFingerHold wrote: post #316
yodon wrote: post #10

Has anybody spotted a similar story of switching from C# to go? As someone who is very fond of C#, I'm definitely curious what I'm missing out on.

I've used C# years ago, then some Go for simple web services and CLIs and now I'm back at C# for those applications. You're missing out nothing if you're already familiar with C#. Go's biggest advantage is that it's much simper to learn. The whole experience feels much more lightweight and straight forward. Very easy to navigate the ecosystem. Other than that, modern C# and .NET has the edge over Go almost everywhere…

Currently learning ASP.NET Core, seems very well put together with quality first-party libraries. I miss Kotlin, but I suspect ASP.NET Core and Blazor SSR makes up for that.

Particularly excited by the fact that Blazor SSR lets you write server-side components. So I can have a statically typed language that lets me think about the UI in terms of components, and a DI container on hand for when I want to break business logic out into services. Love the flexibility all of those things coming together affords. EF Core seems really promising for persistence so far, though I need to play with it more.

Playing with their Identity framework last night I was able to get up and running despite being new to the ecosystem. Very good sign, most of the time integrating auth as a newcomer to a lot of languages ends up being way more than 2 hours worth of work.

Post reply on HN