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

441–450 of 503 posts

Re: One year after switching from Java to Go

#441

Post by tombert »

procaryote wrote: post #213
time4tea wrote: post #156

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…

Yep. Java is really good. Java developer culture is awful. If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

I have said that for awhile: the worst thing about Java is Java developers.

I have some issues with the Java language (though Java 21? Actually pretty ok!), but there's no question that there's a lot of great stuff in regards to libraries in Java land.

A lot of the stuff that's just built into the JDK is already very good, for example. NIO can be a bit hard to work with, but is generally very good, fast, and reliable. A lot of the concurrency abstractions (e.g. BlockingQueues) are really pleasant to work with for most concurrent programs, the different types of mutexes/locks give access to most of the patterns you want, and the thread-safe collections like ConcurrentHashMaps are very boring, in that they work pretty much exactly as I want them to.

If we extend to third party libraries, it's even better. Vert.x and Disruptor, for example, are downright excellent tools for wrangling concurrency.

The issue is that it feels like a lot of Java developers are stuck in 1999; it can be like pulling teeth to even use NIO, which isn't exactly "new" at this point. When I wrote some stuff using BlockingQueues instead of throwing `synchronized` everywhere, people acted like I was grabbing this was some exotic code from a distant land that had never been tried before, When I imported Vert.x into my project because I needed to run a lot of non-blocking concurrent tasks, it required a lot of justification for using it instead of using threads everywhere.

Re: One year after switching from Java to Go

#442

Post by kgeist »

mike_hearn wrote: post #429
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…

It's rather the opposite, it helps avoid bugs when something is terminated, e.g. by ensuring that if an exception is thrown it rolls back a database transaction. Generally you want to do several classes of things with exceptions in web apps: 1. Return a 500, possibly rendering a nice error page. 2. Log why it occurred. 3. Roll back changes you were making at the time in the database. And you might also want to do oth…

Not everything can be wrapped in a single transaction, though. The problem in question involved talking to other services. Frameworks wouldn't help out of the box.

Re: One year after switching from Java to Go

#443

Post by kgeist »

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.

>ignoring an error condition (by either forgetting about it

We rely on linters to catch that, which is pretty easy to implement (no expensive intra-procedural analysis needed, which is the case with exceptions).

>Go can abort at any point as well.

Panics, unlike errors, are exceptional situations which generally should not be caught (a programming error, like index out of range). They're usually much rarer than errors.

Re: One year after switching from Java to Go

#444

Post by kgeist »

gf000 wrote: post #374
Mawr wrote: post #346

Earlier quoted context omitted.

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…

Logging can be a valid handling of error. I just don't believe that most errors can be handled locally so besides returning an error (bubbling up), not much can be done. Go makes this part of the happy path, so neither can be easily seen/reasoned about anymore. Exceptions do auto bubbling up, while languages with ADTs have more strictness than go, and often have some syntactic sugar/macro to help with the common case…

>I just don't believe that most errors can be handled locally so besides returning an error

Sure, but explicit error handling reminds you that the call may fail, and you may want to handle it in some way (or not - then you bubble it up). With exceptions, it creates the illusion of a simple linear flow.

Re: One year after switching from Java to Go

#445

Post by p2detar »

tombert wrote: post #441
procaryote wrote: post #213

Earlier quoted context omitted.

Yep. Java is really good. Java developer culture is awful. If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

I have said that for awhile: the worst thing about Java is Java developers. I have some issues with the Java language (though Java 21? Actually pretty ok!), but there's no question that there's a lot of great stuff in regards to libraries in Java land. A lot of the stuff that's just built into the JDK is already very good, for example. NIO can be a bit hard to work with, but is generally very good, fast, and reliable…

Agree with everything that you wrote. The saddest thing is the job market. It would not be a lie to say the 90% of the jobs list Spring/Boot as a requirement. It's like a framework equals the whole language. This cannot be a good sign. I'm thankful enough to have around 2 decades of Java experience without touching anything named Spring and boy I can tell you I have been having lots of fun with Java. Using Vert.x right now and I like it a lot.

Re: One year after switching from Java to Go

#446

Post by honkycat »

fullstackchris wrote: post #435
scubbo wrote: post #53

Earlier quoted context omitted.

Hard to pick between Python and TypeScript - they have different strengths. TypeScript's type system is more useful (you'd hope, given the name!), but Python "just works" more often for simple use-cases IME (though I have well over double the lifetime experience with Python, so that might be a me-factor rather than a language factor).

Baffling. If you're seriously saying package management for python "just works" and for go "always breaks"... I guess your either a troll, or you've never written production software. And I'm not talking some clever Jupiter notebooks used for some internal auditing or whatnot, I'm talking about customer facing software used by _at least_ 100 people. I'm 12 years in the game and Python has always caused me nothing but…

Agreed! python easily has the worst package management out of all of them!

Re: One year after switching from Java to Go

#447

Post by pm90 »

skeeks wrote: post #148
pm90 wrote: post #11

The startup time comparisons may not seem like a big deal but having an app take several seconds just to start up can burn you really bad in incidents where you want to roll new application versions. And yes, it is possible to engineer around it but I think a better question to ask is why these apps take so goddamn long to start in the first place. There should be some kind of compile or runtime flag to speed this up…

There are a lot of applications where the startup time of several seconds does not matter at all. More likely, for most applications it does not matter. Of course, if you are FAANG, it does, but you should not optimize for that in the beginning.

I have never worked for Faang and have seen this be an issue in every single company Ive worked for. Every one. You don’t need millions of pods. Even a fleet of a few hundred (which isn’t crazy for most small to medium businesses) will cause you much pain if you don’t handle this properly.

Re: One year after switching from Java to Go

#448

Post by tombert »

p2detar wrote: post #445
tombert wrote: post #441

Earlier quoted context omitted.

I have said that for awhile: the worst thing about Java is Java developers. I have some issues with the Java language (though Java 21? Actually pretty ok!), but there's no question that there's a lot of great stuff in regards to libraries in Java land. A lot of the stuff that's just built into the JDK is already very good, for example. NIO can be a bit hard to work with, but is generally very good, fast, and reliable…

Agree with everything that you wrote. The saddest thing is the job market. It would not be a lie to say the 90% of the jobs list Spring/Boot as a requirement. It's like a framework equals the whole language. This cannot be a good sign. I'm thankful enough to have around 2 decades of Java experience without touching anything named Spring and boy I can tell you I have been having lots of fun with Java. Using Vert.x rig…

I don't do web stuff (and hopefully that can stay that way), so I've managed to avoid a lot of Spring stuff, but I am stuck using Spring Streams for some Kafka stuff I'm doing. I'm not going to lie, I don't love it, but that's mostly because it feels like all I do is write YAML files all day.

Vert.x is a lot of fun, and I've gotten pretty decent performance with its SQL libraries in particular, though I'm not sure I'm a huge fan of the EventBus. I've had better luck with LMAX Disruptor, at least for the data-processey stuff that I do.

But as I said, there's a ton of really great libraries in Java. The language isn't perfect, but Java 21 fixes a lot of my gripes, and it's nice to have a ton of really well-tested libraries to minimize how often you have to reinvent the wheel.

Re: One year after switching from Java to Go

#449

Post by tombert »

throw-the-towel wrote: post #378
pjmlp wrote: post #318

Earlier quoted context omitted.

That is actually enterprise culture, using Go won't make a difference in the enterprise space. Ever looked into Kubernetes source code?

At a former job, my coworkers successfully wrote Java in Python.

I haven't touched it since it was still called "AngularJS", but I remember AngularJS kind of felt like they were trying to make it so you write "Java" in "JavaScript". Ember too, if I remember correctly.

Re: One year after switching from Java to Go

#450

Post by Capricorn2481 »

zero_shift wrote: post #359
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…

> 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

> Because it just sounds like a manual version of stacktraces

Because it is. I don't understand it either.

Post reply on HN