Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

361–370 of 503 posts

Re: One year after switching from Java to Go

#361
post #302
post #291

Earlier quoted context omitted.

grep for annotations... That mentality is how you get death by a thousand cuts. Cognitive load matters.

Search within your IDE, do a Google search, whatever suits you. What mentality? And the cognitive load is to RTFM, so that you understand what are you doing. If that leaves any questions you can attempt to do a deep dive. It's not particularly high cognitive load to know that @GET is a get rest endpoint. How is that different without annotations? Documentation is also your best bet at first in case of a normal librar…

This is 2025.

If you can't jump to your own code implementation without having to search for strings, your tech sucks.

And most of your message doesn't even apply. How would I Google or read the manual for my own code?

We're talking about different things it seems.

Re: One year after switching from Java to Go

#362

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…

https://notes.ericjiang.com/posts/751

"PayPal and Wal-Mart have also had high-profile switches to Node.js. Of course, they’re comparing two completely different things to make Node.js look better. In these too-good-to-be-true stories, they’re switching from a gigantic enterprisey codebase to a Node.js app written from scratch. Is there any question that it wouldn’t have been faster? They could have switched to pretty much any anything and gotten a performance gain.

In LinkedIn’s case, they had proxies running on Mongrel with a concurrency of 1. It’s like switching from using one finger to type on a QWERTY keyboard to using ten fingers on a Dvorak keyboard and giving all the credit to Dvorak for a better keyboard layout."

P.S.: Google became so awful that a search for even the direct title of the article does not land it in the top results - just references to it.

Re: One year after switching from Java to Go

#363

Earlier quoted context omitted.

It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.

Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

Do we work at the same place?

Re: One year after switching from Java to Go

#364
post #345

Earlier quoted context omitted.

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

Most Jvm shops/devs I know are still on 11

Re: One year after switching from Java to Go

#365
post #118

Earlier quoted context omitted.

I think CharlieDigital's point is that a bad payload will fail right at the serialisation boundary in case of .NET. We know the problem right there. Now we only need to fix the bad payload. For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

The issue is that this sort of validation boilerplate shouldn't have to be written. The framework should be able to figure it out from the HTTP handler declaration. I suspect this is why FastAPI got so popular in the Python world.

IMO, a lot of the JS world seems mentally fixated on express.js-levels of abstraction still. Anything more is viewed as "magic" and viewed as suspect because it requires learning.

Re: One year after switching from Java to Go

#366
post #240
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…

This is why I don't buy the FP hype

Re: One year after switching from Java to Go

#367
post #276
post #169

This looks like one of the typical "we switched from A to B, whithout actually mastering A, so B is alright" kind of posts. Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX. No mention of AOT compilers, JIT caches, and so forth.

pprof data via HTTP is part of the Go stdlib and is pretty close, good enough for 95% of cases. One could argue you need those tools less in a Go codebase anyway ;) AOT is mentioned and JIT is not relevant.

pprof isn't not even close to what Visual VM and Flight Recorder are capable of, hence why then there are stuff like open telemetry integration, which require active coding to provide sensible data.

This is the only mention of AOT

> Java's JIT (Just-In-Time) compiler and Go's AOT (Ahead-Of-Time) compiler are definitely two very different approaches and therefore hard to compare.

Zero content on all the options since Excelsior JET and other commercial alternatives came to be, or the free beer alternatives available nowadays.

JIT caches and plain old JIT aren't the same.

JIT caches are similar in concept to AOT with PGO, with the difference that instead of doing that once for the lifetime of the executable with data from test runs, it gets updated after each production execution.

Re: One year after switching from Java to Go

#368

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

That's the problem isn't it ? The Java of 8+ years ago is always compared to the Rust/Go/Python of today. (I am also guilty of this)

Re: One year after switching from Java to Go

#369

Earlier quoted context omitted.

It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.

Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

People can write bad code in any language

Re: One year after switching from Java to Go

#370

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.

A real monolithic app dealing with videostreaming that I have been working recently, was based on Spring Boot and AWS SDK and it was a 82 Mb jar file. It had the drivers, oauth stuff, a couple of template engines for business reasons (Handlebars and Thymeleaf), database and queue drivers etc. It could be maintained and extended by a junior developer, because it had established design patterns and they only needed to follow some project conventions. We had multiple releases per week at engineering cost of less than 25k€ per year. I would not be able to build something like that with that budget on Go.
Post reply on HN