←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 6 comments | 18 Feb 25 16:55 UTC | HN request time: 0.716s | source | bottom
Show context
time4tea ◴[19 Feb 25 07:02 UTC] No.43099396[source]▶
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 is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

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.

Just use new() it's pretty fast.

replies(12): >>43099426 #>>43099935 #>>43100071 #>>43100330 #>>43100562 #>>43101034 #>>43101071 #>>43101189 #>>43101914 #>>43102326 #>>43102666 #>>43143349 #
smusamashah ◴[19 Feb 25 09:37 UTC] No.43100330[source]▶
At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have.

Someone shared a Job posting which asked for "no java experience". It was funny.

replies(2): >>43100514 #>>43101098 #
theshrike79 ◴[19 Feb 25 11:53 UTC] No.43101098[source]▶
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.

replies(2): >>43101649 #>>43102781 #
1. kuschku ◴[19 Feb 25 13:02 UTC] No.43101649[source]▶
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.

replies(3): >>43101965 #>>43102040 #>>43103223 #
2. hlpn ◴[19 Feb 25 13:33 UTC] No.43101965[source]▶
Do we work at the same place?
3. Twirrim ◴[19 Feb 25 13:41 UTC] No.43102040[source]▶
People can write bad code in any language
replies(1): >>43102140 #
4. gorjusborg ◴[19 Feb 25 13:50 UTC] No.43102140[source]▶
It is almost like language is a conduit for something, I wonder what though. I will have to think on it.
5. CBLT ◴[19 Feb 25 15:38 UTC] No.43103223[source]▶
Hey, sorry, that might have been me. I did that then left the company.

In my defense, I had to hack around a different Python library also manipulating sys.path, which nobody likes except this one dev team in a different timezone. They somehow got a director to declare that I would fix this issue they self-created before they woke up in 8h, and I wasn't allowed to rip out the library. So, ugly sys.path manipulation in the exact way that library wants. Not proud of it, but it sounds like you were given time to engineer an actually correct solution.

replies(1): >>43112986 #
6. kuschku ◴[20 Feb 25 10:05 UTC] No.43112986[source]▶
The project is an open source project, so it's likely not your fault :)

I can fully see how and why this might have grown historically in ye olden days of python2, but it's not sustainable to continue adding floors ontop of a rotten foundation. Code needs maintenance like anything else, and far too often there's no budget or time available for it. Even if that maintenance would reduce the overall workload.