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

451–460 of 503 posts

Re: One year after switching from Java to Go

#451

Post by tombert »

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…

> You do realize that Java is objectively less verbose than Go?

I might agree if you're speaking about Java since ~11 or so.

One of my biggest complaints about Java, especially before the lambda syntax caught on, was how many extra files it made me create. I felt like every project had lots of wrapper classes, and people would make a make a file for each class.

You could argue that that was "bad" Java and they should have nested the classes, and that's fair enough, but it certainly wasn't uncommon Java. It artificially makes the language feel way too verbose if you have ten files more than would be necessary in a comparable language.

Once people started to embrace the lambda syntax, I feel that Java got immediately more fun to write; you weren't constantly creating one-off instantiations of interfaces or classes (well, at least not explicitly anyway), and the language felt considerably more streamlined.

Java 21 is actually one of the most pleasant surprises I've had in quite awhile in the tech world, in that I'm actually having fun writing Java. Sealed interfaces and record patterns make some code considerably more pleasant, and I actually have been writing Java in my free time, which is something that I would have said would never happen if you had asked me five years ago.

ETA:

https://youtu.be/jgkEHoc3YUw?t=288 See! I even said I would never enjoy writing Java!

Re: One year after switching from Java to Go

#452

Post by pjmlp »

mike_hearn wrote: post #421
ReflectedImage wrote: post #382

Earlier quoted context omitted.

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

But people here are comparing a language standard library with a framework like Spring, which doesn't make sense. The Java standard library has a web server in it, it has JDBC. You could use those directly. That's comparable to the Go standard library. For real apps people don't do this because they want a lot more, like simplified database access or session management. Look at this: https://pkg.go.dev/database/sql I…

And it misses something like Swing, which while not perfect, does the job and the best Go can hope for is Fyne, as third party.

Multithreaded collection types.

Configuring scheduling algorithms.

Pluggable services, cryptography algorithms, filesystem.

Sane way to manage dates, granted the original one was a bit clunky, but way better than parsing strings.

Sometimes I wonder if folks that criticise Java, and .NET, actually spend any time learning their standard libraries in practice.

Re: One year after switching from Java to Go

#453

Post by pjmlp »

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

And many folks still code in C89, C99, C++98, Python 2, .NET Framework....

Language is not to blame for unwillingness to move forward.

Re: One year after switching from Java to Go

#454

Post by ivan_gammel »

zipy124 wrote: post #427
ivan_gammel wrote: post #373

Earlier quoted context omitted.

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.

Another re-phrasing of my comment is that perhaps using Go they do not require the strong senior to kick it off. Otherwise yes there is always the argument of "they're just using it wrong" etc... ultimately: ¯\_(ツ)_/¯

No. Go is worse simply due to lack of established design patterns. Spring (just like Angular) forces to build things in a certain way and has a lot of reasonable defaults. E.g. CSRF protection is enabled by default in Spring Security. CORS configuration is trivial. Magic? Yes. In Go juniors won’t even think it is necessary and may not figure out that they need a 3rd party library for that (or build it correctly).

Re: One year after switching from Java to Go

#455

Post by pylua »

gf000 wrote: post #342
pylua wrote: post #330

Earlier quoted context omitted.

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.

Right. I didn’t started digging into it until I realized the application was clearly sluggish in certain scenarios. As I am doing this for fun I am going to see what kind of speed up I get in rust for this.

Re: One year after switching from Java to Go

#456

Post by pylua »

rootlocus wrote: post #153
pylua wrote: post #66

Earlier quoted context omitted.

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…

Have you tried AoT compilation with graalvm?

No, the product has a lot of aop and I figure it would be difficult to make that work.

Re: One year after switching from Java to Go

#457

Post by Capricorn2481 »

ratorx wrote: post #425
Capricorn2481 wrote: post #422

Earlier quoted context omitted.

> And once you start doing it with exceptions, there’s not much difference in the code you end up writing between errors and exceptions The difference is where you want to catch the error, and not doing a bunch of "plumbing code" for intermediate callers that don't need to know about that error. > because the norm in Java is to silently pass up exceptions as that is the most ergonomic thing Adding args to an exceptio…

> difference is where you want to catch the error Catching is pretty similar no? In Java you match by type and in Go, you match by `errors.Is`? I guess the static checking in Java js better, but in terms of code written it is no different. > additional args to error in Go could mean changing dozens of files Just to be clear, here we are talking about a function that already returns an exception/error and adding args…

> Catching is pretty similar no?

In Go, you have to "catch" it at every call level.

> Just to be clear, here we are talking about a function that already returns an exception/error and adding args to it

Yes, but adding an arg doesn't mean modifying the error string, it means adding another piece of data which could be a different type. That's another var, and now every call level has to update to pass along that new var. Unless you change the var from a string to a map, which is a whole different set of headaches.

> Arguably, this type of thing is harder in Java. Adding a new type of exception requires modifying all dependent callers to declare/handle the exception

Only if they need to handle it. If you just want it to bubble up, that function doesn't even need to know about that error or what args it has. That's not the case in Go. Every function has to know about every error that passes through. It's the difference between changing two files and changing 10 files.

Re: One year after switching from Java to Go

#458

Post by packetlost »

AYBABTME wrote: post #390
unscaled wrote: post #290

Earlier quoted context omitted.

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.

Eh, I don't think iteration times in Rust are nearly as bad as you think. During a realistic development loop compilation is <1s in most situations thanks to incremental compilation and tests are fast unless you have synthetic slowdowns such as sleeps or IO (which would effect both languages equally).

Re: One year after switching from Java to Go

#459

Post by ted_dunning »

CharlieDigital wrote: post #275
ted_dunning wrote: post #159

Earlier quoted context omitted.

[flagged]

This is satire, right?

No.

It is just an explicit rendition of a complex topic.

Do you have a more economical example that handles all of the corner cases of cleanup routines throwing errors?

Re: One year after switching from Java to Go

#460

Post by aqueueaqueue »

chamomeal wrote: post #377
aqueueaqueue wrote: post #227

Earlier quoted context omitted.

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.

DI can be manual DI - passing dependencies. I think the hallmark is lack of "new" in your classes (or probably lack of specific imports in a non OO idiomatic language like JS)

IoC is more about design than dependency resolution mechanisms.

Post reply on HN