Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

201–210 of 503 posts

Re: One year after switching from Java to Go

#201
post #189
post #85

Earlier quoted context omitted.

The JVM starts in milliseconds Probably you're loading many thousands of classes...

It certainly tells me it does. i can hit 'run unit test', sit back in my chair and zone out for 5 seconds, then come back and read that the test took 22ms.

haha well your test did take 22ms, but starting the JVM and loading all the classes and all your dependency injection stuff probably took 5s. You can test it yourself with a tiny hello world, it's pretty fast to start.

Re: One year after switching from Java to Go

#202

Earlier quoted context omitted.

> The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing This is not possible in Java or C#? Both of those languages are so simple to grasp.

> This is not possible in Java or C#? Both of those languages are so simple to grasp. Not really, no. Apart from the cognitive burden of knowing the test framework in use, the DI tooling in use, the Mocking framework in use, plus all the annotations that each framework may want/need, almost none of which applies to the Go projects I've seen, the languages themselves have drifted away from simplicity. I used to progra…

> C# is approaching C++ levels of syntax indecipherability.

Can you post an example of such new syntax? In my experience C#'s syntax is getting cleaner.

Re: One year after switching from Java to Go

#203

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…

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

No, people use it because we don't want to reinvent the wheel.

Spring is well documented and Spring Boot gives you a set of dependencies that all work together.

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

Re: One year after switching from Java to Go

#204
post #191
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…

> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. > I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself. DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap imple…

If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.

Re: One year after switching from Java to Go

#205
The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you.

It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO.

You can still do inversion of control without an IoC container—instantiation works just fine! Look at Go’s HTTP middleware pattern with structural typing and first-class functions. No config files, no annotation magic, just composition, testability, and code small enough to hold in your head.

Re: One year after switching from Java to Go

#206
post #66

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…

> The startup time is also a real problem, as you really want to be able to scale up pods quickly.

I was learning a bit of spring last week and a spring boot web application, generated via the web interface boots in like 800msec:

    ...
    Initializing Spring embedded WebApplicationContext
    Root WebApplicationContext: initialization completed in 339 ms
    Tomcat started on port 8080 (http) with context path '/'
    Started DemoCourseApplication in 0.746 seconds (process running for 1.012)
    ...
Reusing my experience from other technologies... I'd say the issue might be in whatever you're doing in your initialization and/or how much stuff you're loading.

Looks like the core spring is decently fast, to me.

Re: One year after switching from Java to Go

#207
post #180

Earlier quoted context omitted.

I’m yet to see a former Java developer who uses the idioms of the language they currently use. They all just write Java in a different language.

That is a f unction of the developer, not of the language, i.e. f (dev), not f (lang) ;) Replace Java with star and that statement still holds true (for some people). Hence the statement that you can write FORTRAN in any language. https://blog.codinghorror.com/you-can-write-fortran-in-any-l...

[flagged]

Re: One year after switching from Java to Go

#208

The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you. It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO. You can still do inversion of control withou…

> It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you.

> No config files, no annotation magic, just composition, testability, and code small enough to hold in your head.

This. When I look at code I should just be able to follow it and know what's happening. The whole annotation magic and config files makes it hard to understand the flow of things.

Re: One year after switching from Java to Go

#209

The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you. It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO. You can still do inversion of control withou…

> heavyweight ecosystem

Try micronaut once. It does DI and even ORM mapping (with micronaut data jdbc) at compile time and avoids most reflection.

Re: One year after switching from Java to Go

#210
post #25

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

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…

> spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

Yes, but the point is 1) you don't have to write it yourself and 2) it does 'the right thing' even if your junior dev straight out of BS CS wouldn't know how to write it.

There are, of course, caveats and not all frameworks are created equal and any tool can be misused. But I find DI very useful. Personally I'd recommend Uber's Fx framework and underlying dig library.

Post reply on HN