←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 5 comments | 18 Feb 25 16:55 UTC | HN request time: 0.88s | source
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 #
1. dominicrose ◴[19 Feb 25 10:19 UTC] No.43100562[source]▶
I tried truffleruby for the adventofcode challenges. Almost everything ran faster with normal ruby. I got a stack too deep error in truffleruby that I didn't get in normal ruby. I don't recall having more problems with memory with one or the other. There was one case where truffleruby was really useful though.

Thus I'm with you that it's not a systems programming language. It seems good for processes that stay ON, like servers.

But then when compared with PHP, during development you don't need to worry about the server, it just takes the most recent version of your code. Surely hot-reload can be a solution with java, but in practice it's a complication, especially if you're part of a team/project where there is no hot-reload support.

replies(3): >>43100777 #>>43101271 #>>43102143 #
2. HumanOstrich ◴[19 Feb 25 10:55 UTC] No.43100777[source]▶
I don't follow. Seems like the issues you had were due to truffleruby and how it implements ruby's internals on the JVM.

That's not a Java/Kotlin/JVM issue.

3. gf000 ◴[19 Feb 25 12:21 UTC] No.43101271[source]▶
Why would you expect any speedup for programs that run for a split of a second?
replies(1): >>43157402 #
4. Twirrim ◴[19 Feb 25 13:51 UTC] No.43102143[source]▶
The JVM doesn't attempt to compile a method until a method has reached 10,000 executions. So it's extremely likely your code ran the entire time in interpreted mode. Even if a method did get flagged as hot, you've then got the time taken to do the actual compilation to native code to contend with.

If you're trying to write systems code and want to use the JVM, GraalVM can do full ahead-of-time compilation and will get you almost instant start up with all methods natively compiled.

5. dominicrose ◴[24 Feb 25 09:16 UTC] No.43157402[source]▶
Indeed, nothing really surprising. truffleruby+graalvm started to be useful for programs that took roughtly 15s or more to run.