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

341–350 of 503 posts

Re: One year after switching from Java to Go

#341

Post by Cthulhu_ »

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…

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

Re: One year after switching from Java to Go

#342

Post by gf000 »

pylua wrote: post #330
gf000 wrote: post #328

Earlier quoted context omitted.

Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.

That’s the pain point - well written java code may not be the most performant depending on the situation. It wasn’t just optional but other areas as well.

That's not my experience, though game development is certainly a niche and Java may not be the top choice for that.

You might sometimes have to reach for SoA-like structures and reference them via indices, at least for the core ECS, but for the rest you can easily use bog-standard Java -- not everything has to be "ultra-fast, specially written java", just certain hot loops.

Re: One year after switching from Java to Go

#343

Post by Cthulhu_ »

fweimer wrote: post #261
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…

How does Go avoid getting bogged down by middleware-oriented programing in practice? I think most large-scale programming in organizations tend to converge on that because it sort of works. Is it that people who like this kind of stuff write microservices for deployment on Kubernetes clusters?

Go itself doesn't do anything about that, nor does Java or JS dictate anything about using middleware.

I can't speak for the ecosystem / developers though; there are plenty of examples where e.g. HTTP request handlers are wrapped in several onion layers of middleware itself. But, there's also an emphasis on keeping things simple and lightweight.

What kind of middleware are you thinking of when you mention things getting bogged down?

Re: One year after switching from Java to Go

#344

Post by lenkite »

okeuro49 wrote: post #333
lenkite wrote: post #325

Earlier quoted context omitted.

In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc…

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

Re: One year after switching from Java to Go

#345

Post by demi56 »

lenkite wrote: post #334
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?

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+

Re: One year after switching from Java to Go

#346

Post by Mawr »

gf000 wrote: post #279
kgeist wrote: post #216

Earlier quoted context omitted.

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.

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 one of the valid ways of handling it, depending on context.

Re: One year after switching from Java to Go

#347

Post by Cthulhu_ »

3uler wrote: post #175
roncesvalles wrote: post #171

Earlier quoted context omitted.

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…

And yet Uber wrote fx[1] to support DI in their golang services. It’s clearly a useful pattern when working on large services. [1]: https://github.com/uber-go/fx

Just because a known company uses it doesn't mean it's authoritative; there's likewise functional programming libraries built by big companies, but FP should also be avoided in Go because it's not a functional language and not optimized for it.

Re: One year after switching from Java to Go

#348

Post by mattgreenrocks »

nprateem wrote: post #270
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.

Try understanding what spring boot is doing. Annotation soup. It's practically impossible for a beginner to Spring to debug.

IntelliJ seems able to locate all potential implementations at injection points just fine.

Re: One year after switching from Java to Go

#349

Post by FrustratedMonky »

gf000 wrote: post #284
cies wrote: post #246

Earlier quoted context omitted.

Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

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.

Re: One year after switching from Java to Go

#350

Post by Cthulhu_ »

zdragnar wrote: post #104
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.

The languages aren't, strictly speaking, so much the problem as are the massive frameworks configured via distant files with lots of DI and reflection magic involved. Go has some large frameworks, but the community frequently suggests they aren't needed and that the standard library is enough.

Exactly; if you ask about for example a test assertion or mocking library like in Java, you get told to not use it. These libraries often add a DSL of sorts, meaning you have to relearn them.

Granted, Go's testing library / setup is also a bit of a jump from regular Go code (especially things like table tests). But the assertions are just `if`s.

Post reply on HN