We run mostly Java apps with a few Go apps. What I miss with Go, maybe just because I'm not as familiar and don't know where to look, is all the runtime analysis that's built in. Thread dumps, heap dumps, and even flight recorder profiling is all built in to the JVM so it works with all apps everywhere. When a Go app suddenly slows down it's very difficult to determine why unless the app was coded to provide the righ…
I actually much prefer go ‘s runtime tooling. Pprof has everything I need built in; heap, cpu, blocking, mutex contention. And don’t need additional tools to visualize the collected data. https://pkg.go.dev/net/http/pprof@go1.24.0
One year after switching from Java to Go
91–100 of 503 posts
Re: One year after switching from Java to Go
#92The best thing about Go is no Spring framework. I like Java but finding Java projects without Spring is difficult.
I've been a frequent Java programmer since its earliest days (started around 1996) and I've yet to ever use Spring.
None of the bad parts of Java are actually a part of Java!
Re: One year after switching from Java to Go
#93Earlier quoted context omitted.
Agreed, the spring framework is completely against the spirit of Java. Yeah, auto-wiring was a terrible idea - why do I have to guess what components are going to be pulled in? And why do I have to figure this out a runtime? The features of Spring Boot are nice, but Spring itself should probably be put out to pasture. Someone needs to write a good alternative to Spring and start promoting it like crazy (probably some…
went to springone conference in vegas in 2016. eight years later, there are still no good alternatives :)
Re: One year after switching from Java to Go
#94Java is a general purpose application development language. Go is a system language that isn't as deep as Rust. They are very different things and comparing them doesn't make any sense. Like the people comparing Rust to JavaScript, these are not interchangeable.
Re: One year after switching from Java to Go
#95Earlier quoted context omitted.
I worked on Wire right at the beginning, happy to answer any questions about it.
Given that the development of Wire seems to have slowed down, do you still recommend using Wire for dependency injection in Go projects? How has your perspective on its design philosophy evolved over time?
The goal at the time I thought was very sound: it was a massive PITA that Go programs that ran on cloud servers (of which I would hazard most of them do) were not Write Once Run Anywhere. It was all the same stuff, right? A blob store. A SQL backend. Etc etc. What we wanted was to say “you write a Go program, here run it on GCP. Then Azure. Why not AliBaba if you’re in China”.
What I am no longer convinced of today is that anyone is really looking for those greased rails because it’s _so much more complicated_ to run on cloud servers than I envisioned. Surely it was going to get more simple? But it didn’t. Networking, authorization, scaling, Kubernetes. The list goes on and on.
A fully uneducated guess is that Wire does what people who come to it want it to do, but it’s not attracting new users because the use cases are more constrained than envisaged.
Re: One year after switching from Java to Go
#96Yeah. I see Android app development is still mostly dominated by Java/Kotlin. Of course you can do it with Go, e.g: https://fyne.io. Never try to write something serious with it, just messing around with the examples.
Re: One year after switching from Java to Go
#97Re: One year after switching from Java to Go
#98> 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…
Re: One year after switching from Java to Go
#99Earlier quoted context omitted.
To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.
What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only cas…
Re: One year after switching from Java to Go
#100> 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…
> 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.