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

491–500 of 503 posts

Re: One year after switching from Java to Go

#491

Post by tored »

DrScientist wrote: post #253

Never quite understood the attraction of dependency injection frameworks. Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so? Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime? Just seems as a very complicated way to avoid creating package c that brings together package a and d…

Dependency injection containers can be overly complex and allow complex configurations, too much magic.

That is why I kept my container library simple, you read thru all the source in less than 15 minutes.

What I like about it is that it is natural to use composition with classes, it encourages to create classes to divide your application into reusable parts.

And with my library all you do is to put the dependent class in the constructor. My library can without much effort be replaced with normal factory, that is by design.

Warning PHP https://github.com/paketphp/bero

Re: One year after switching from Java to Go

#492

Post by ivan_gammel »

conwaytwitty wrote: post #310
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…

Spring Boot startup time is indeed a problem, especially when scaling horizontally on low cpu nodes. If your environment allows for burst cpu usage until ready to accept traffic, you can start up really fast as spring does so much reflection magic during startup that can't be done during compilation "trivially". You can include hints for runtime configuration from a build, but it doesn't do much to help in really low…

This actually makes me wonder if it is possible to preserve post-startup state and then restore it as a way to mitigate long computational stage during startup. I bet it is, maybe we could just serialize the application context and restore it.

Re: One year after switching from Java to Go

#493

Post by whizzter »

cies wrote: post #246
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

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

Annotations were adopted to cut down on the massive amounts of XML that was used to configure everything beforehand, still a lot was loosely wired for "extensibility" and people have learned that it was 99% overengineering so that's cut down these days in various ways.

Re: One year after switching from Java to Go

#494

Post by sn9 »

derekperkins wrote: post #482
sn9 wrote: post #432

Earlier quoted context omitted.

Discord had a pretty famous transition from Go to Rust [0]. [0] https://discord.com/blog/why-discord-is-switching-from-go-to...

They didn't have particularly great reasons to migrate at the time besides the team wanting to write rust. That article is just trying to provide validation

"With the Go implementation, the Read States service was not supporting its product requirements. It was fast most of the time, but every few minutes we saw large latency spikes that were bad for user experience. After investigating, we determined the spikes were due to core Go features: its memory model and garbage collector (GC)."

Re: One year after switching from Java to Go

#495

Post by codr7 »

throwaway2037 wrote: post #474
codr7 wrote: post #112

Earlier quoted context omitted.

Don't know, every time I try to do anything beyond trivial using Go generics I run into some kind of issue. They haven't been around that long, it takes time for ideas to mature.

> anything beyond trivial using Go generics This is the first complaint that I have heard about Go generics on this board. I believe you. Can you share a specific example? It might spur some interesting discussion.

Haven't written much Go the last year and a half...

Mostly novel limitations that I'm not used to from C++.

Instantiating generic parameter types is one thing I couldn't figure out at some point, but that's pretty much useless in C# and impossible in Java if I remember correctly.

I recognize the frustration from following implementations in both Java and C# though, it takes a while for generics to settle, each implementation has its own quirks.

Re: One year after switching from Java to Go

#496

Post by lexicality »

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.

The entire point of writing rust is that you're trading writing speed for runtime safety. It takes longer to write but you can guarantee you're never going to have a nil pointer panic or race condition.

Unless you're doing something super weird your infra code is gonna be running for way longer than you spend writing it so who cares if it takes an extra 20%/30%/50%/whatever time to write?

Re: One year after switching from Java to Go

#497

Post by munksbeer »

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…

> The issue is that it feels like a lot of Java developers are stuck in 1999

Where are you working that you encounter these people? I've been doing Java for about 15 years now (C++ before that) and as the years have gone by I just don't encounter this stuff. I do work in finance technology, so we're not doing crud apps, maybe that makes a difference. Granted, there is a lot of "C in Java" code around in this industry.

Re: One year after switching from Java to Go

#498

Post by scubbo »

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…

No, that wasn't what I was saying. I was asked a tangential question about which language I preferred; and considering the language _itself_ rather than the ecosystem, I find that Python is the one that typically "just works" - that is, the barrier between thought/design and expression is smallest.

I've repeatedly heard terrible things about Python's packaging, and I have to believe that they're true, even if I've never experienced them myself. And, yeah, you've guessed partially correctly - my own 14 years of professional experience have been primarily with Java and TypeScript, with Python being my language of choice for _personal_ projects. So - yes, I never have written production Python.

To once again be clear, I'm not making any claims that Python's packaging is better than Go's. I'm making two separate and unrelated claims (because the latter was prompted by a tangential question):

* For someone currently building development tooling for a polyglot company, Go's dependency-management system requires more special-casing (both for publication and for consumption) than the others combined.

* For me personally, when translating thoughts/algorithms/designs into code (without considering publication), Python is the language in which I can do so fastest and most intuitively. Never having published a package with it, I've never had to engage with that side of things - I believe folks who tell me that it sucks, but from the consumers' side `source .venv/bin/activate; pip install -f requirements.txt` has always works flawlessly for me.

Re: One year after switching from Java to Go

#499

Post by coldtea »

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…

>Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

I dunno, some databases and things like Lucene are written in Java.

Re: One year after switching from Java to Go

#500

Post by rr808 »

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…

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

Isn't async unnecessary now? Threads are now cheap enough that its much easier to write sync'd calls on a thread.

Post reply on HN