Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

61–70 of 503 posts

Re: One year after switching from Java to Go

#61
As a Java developer...

If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'.

Java is good right now because most problems have libraries to do what you want. Most formats have APIs.

It's not perfect in any area - the start-up time is a bit lame, you have to write 'anti-Java' to really get close to native performance. But it's quick to build in, the toolchain is solid, the dependency framework works better than all the alternatives. It's a 95% language that's been made development friendly.

(Golang somehow added versioning late and is 'Git+' at best, NPM unpublished stuff, C++ is hell, etc. Rust crates just doesn't have much but seems to have been built properly).

But if you're working in a new space (crypto, AI, cloud) then you should definitely look at what the state-of-the-art libraries are written in.

And you should think real hard before you implement your app in anything else. Because there will be a real, long term, painful penalty unless you get VERY lucky and the entire ecosystem pivots to your language.

Re: One year after switching from Java to Go

#62
post #12

Agree. Go is a joy to use. Java is okay but struggles with scaling unless you have the money to burn for this. To scale up servers in Java requires spinning up highly priced servers with lots of RAM, which that is a lot of money. Using a low spec server is cheaper but you will get more JVM crashes and have to waste time doing more JVM tuning to prevent them. This is not even talking about having lots of 'microservice…

> Would stay really far away from JavaScript or TypeScript for anything backend. IDK, TypeScript types are extremely ergonomic, and if you're not overzealous makes everything very readable, and given many things are I/O bound anyway, it doesn't matter much.

I guess you just dont know the domain well enough to understand the kind of issues strong typing and compiled software is solving.

Re: One year after switching from Java to Go

#63

Going back to first principles, nominal typing is what I miss most with Go. I get the utility of structs + interfaces + structural typing, but most of the time there is more benefit in declaring that a type nominally implements an interface when that is the intention. Code is far easier to read and understand that way, both for developers and tooling. I suppose exclusively structural typing would be more acceptable i…

Are you aware of the trick of "var _ foo.RequiredInterface = myType{}" to make the compiler enforce that a struct implements a given interface?

Is what you seek a nicer syntax for this or does what you speak of bring something more feature wise?

At least IntelliJ IDEs will always make it clear what interfaces all your structs implement.

Re: One year after switching from Java to Go

#64

it's really weird to see a "Dependency Injection & Context" section as if Golang's context has anything at all to do with DI. in particular, reading between the lines here: > 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. suggests to me that they've implemented one of the Golang anti-patterns…

> as if Golang's context has anything at all to do with DI Yes, Go's context can be used as a DI container.

I thought it was mostly used to terminate an asynchronous event?

Re: One year after switching from Java to Go

#65
post #20

seems to be mostly criticism of spring rather than java the company behind spring should ruin go by porting their crappy library to it (oh look, it's broadcom....)

Agreed, the spring framework is completely against the spirit of Java. Yeah, auto-wiring was a terrible idea - why do I have to guess what components are going to be pulled in? And why do I have to figure this out a runtime?

The features of Spring Boot are nice, but Spring itself should probably be put out to pasture. Someone needs to write a good alternative to Spring and start promoting it like crazy (probably something exists).

Re: One year after switching from Java to Go

#66

As a Java developer... If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'. Java is good right now because most problems have libraries to do what you want. Most formats have APIs. It's not perfect in any area - the start-up time is a bit lame, you have to…

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

I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze?

Re: One year after switching from Java to Go

#67

Earlier quoted context omitted.

> Would stay really far away from JavaScript or TypeScript for anything backend. IDK, TypeScript types are extremely ergonomic, and if you're not overzealous makes everything very readable, and given many things are I/O bound anyway, it doesn't matter much.

I guess you just dont know the domain well enough to understand the kind of issues strong typing and compiled software is solving.

Please do tell, what typescript, node and a few dependencies cannot do here.

Re: One year after switching from Java to Go

#68
I'm pretty fond of Java; it's definitely a superior language to Go if you ask me, which I've also written a ton of code in.

But I stay away from Spring Boot, end the entire EE stack of crap that came before it, if at all possible.

I've had more success adding whatever I need on top of embedded Jetty.

It's mostly a cultural problem, no one is forcing you to go the AdapterFacadeInjectionBuilderWhatever way.

I've been working on a library to simplify interfacing with relational databases for a while now. With several implementations in Go and other languages. And the java version looks at least as nice as the rest to my eyes:

https://github.com/codr7/tyred-java

Re: One year after switching from Java to Go

#69
post #37
post #29

Earlier quoted context omitted.

DI exists in Go, but it's not ubiquitous like it is in the C# or Java worlds. Last time I used Go, I used "wire" for DI and was pretty happy with it.

I worked on Wire right at the beginning, happy to answer any questions about it.

Given that the development of Wire seems to have slowed down, do you still recommend using Wire for dependency injection in Go projects? How has your perspective on its design philosophy evolved over time?

Re: One year after switching from Java to Go

#70
post #68

I'm pretty fond of Java; it's definitely a superior language to Go if you ask me, which I've also written a ton of code in. But I stay away from Spring Boot, end the entire EE stack of crap that came before it, if at all possible. I've had more success adding whatever I need on top of embedded Jetty. It's mostly a cultural problem, no one is forcing you to go the AdapterFacadeInjectionBuilderWhatever way. I've been w…

[flagged]
Post reply on HN