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

301–310 of 503 posts

Re: One year after switching from Java to Go

#301

Post by CharlieDigital »

itsthecourier wrote: post #292
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…

yeah, this author reminds me of the guys who think simpler is better because they haven't read the whole documentation on why the thing is complex in first place, do they end up reinventing the wheel badly as they start to grow and discover problems already solved in mature frameworks the lack of specific mention of scenarios and features beyond dependency injection suggests ignorance IMHO

I find this very common when working with JS backends. Once you get serious, you end up replicating a lot of the complex concepts of frameworks like Spring or .NET

Re: One year after switching from Java to Go

#302

Post by gf000 »

hu3 wrote: post #291
gf000 wrote: post #280

Earlier quoted context omitted.

You... literally can? Yeah, you may have to grep for the annotation's name, but it's not like it's hidden/closed source/whatever.

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 library function call. Jumping into that codebase can also be quite involved, depending on what it does.

Re: One year after switching from Java to Go

#303

Post by cs02rm0 »

I really liked Dropwizard. It had a philosophy of picking a set of tools that could help people get up and running with a java web application quickly and that would serve them well for a long time, choosing the best tool for the job.

Then Spring boot came along where they defaulted to the much fatter Tomcat, apparently just to be different, and then went down the list of libraries and instead of picking the best one, they picked the Spring one.

I never understood that philosophy, but it won out. It looked at lot to me like no one ever got fired for choosing IBM/Microsoft. But it was so much worse. Other frameworks have improved on what Dropwizard offered for startup times, etc. but still don't seem to have gained the traction to unsettle Spring.

Re: One year after switching from Java to Go

#304

Post by unscaled »

bcrosby95 wrote: post #134
arnath wrote: post #44

Earlier quoted context omitted.

This comment is about a very minor part of what you said, but isn’t the whole point of a DI framework to write code you’d have written anyway to save you time?

DI frameworks save you from writing trivial code, and it masks dependency insanity. This is why I don't use it even in Java. If the codebase gets to the point where a DI framework is really useful then you've fucked yourself over.

To be fair, traditional Java EE apps often required a DI framework, because you couldn't control the main entry point of the program, and the entry point to your code was a class with a default no-argument constructor.

This is still insanity, but the insanity comes from Java EE rather than the apps themselves.

Re: One year after switching from Java to Go

#305

Post by gf000 »

38 wrote: post #130
codr7 wrote: post #107

Earlier quoted context omitted.

I don't see that as a problem at all, just like I don't see header files in C++ as a major problem, there are benefits as well and Java has the best IDEs of any language I've worked in except maybe SmallTalk.

Java has the best IDEs, because as a language development is essentially impossible without one. contrast with Go where I can put as many types into one file as I like, and I can (and do) use Go without an IDE, both personally and professionally

What part of Java development is impossible without an IDE?

It's a stupidly simple language.

Just because people actually use it and thus IDEs were developed to aid the development process doesn't make it a necessity at all. I have programmed Java countless times from vim without any plugins. The only pain point is imports, which would be similarly painful in any other language ever created.

Re: One year after switching from Java to Go

#306

Post by maccard »

winrid wrote: post #283
maccard wrote: post #230

Earlier quoted context omitted.

But that's our point - you're saying java is fast (and it is ripping fast once it gets going) and the startup is fast, unless it's not.

Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think. It could also be when he's hitting "run test" it's actually "compile and run"...

> Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think.

Ok, maybe I misspoke about the "JVM" startup. But the time between `mvn test` and it actually logging the first line of user code was in the region of 15 seconds. Every java project I've worked on has had startup time issues once they're bigger than a toy project.

Saying "the JVm startup is fine, it's just the class loader that's slow" reinforces the point of "it's slow to startup"

> It could also be when he's hitting "run test" it's actually "compile and run"...

This would be true in C# too, and in go. Both of those tools have much quicker compilation times IME than java, which is just a nice plus.

Re: One year after switching from Java to Go

#307

Post by arccy »

divan wrote: post #285
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

> Java is really good. Java developer culture is awful. First we shape our tools, then our tools shape us.

the Old Ones shape the tools, the tools shape the rest of us

Re: One year after switching from Java to Go

#308

Post by xxs »

pjmlp wrote: 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.

Pretty much. There are lots of post in that form, it makes for a good self tapping on the back and few blog posts - without any questions answered.

OTOH - if that's what makes run the business, I'd not argue.

Re: One year after switching from Java to Go

#309

Post by gf000 »

dominicrose wrote: post #248
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…

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, li…

Why would you expect any speedup for programs that run for a split of a second?

Re: One year after switching from Java to Go

#310

Post by conwaytwitty »

pylua wrote: post #66
philipwhiuk wrote: post #61

As a Java developer... If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'. Java is good right now because most problems have libraries to do what you want. Most formats have APIs. It's not perfect in any area - the start-up time is a bit lame, you have to…

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

Then you can of course just do native images, but you lose some of the spring "magic", and might be annoying to refactor towards.

Post reply on HN