Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

461–470 of 503 posts

Re: One year after switching from Java to Go

#461
post #425

Earlier quoted context omitted.

> difference is where you want to catch the error Catching is pretty similar no? In Java you match by type and in Go, you match by `errors.Is`? I guess the static checking in Java js better, but in terms of code written it is no different. > additional args to error in Go could mean changing dozens of files Just to be clear, here we are talking about a function that already returns an exception/error and adding args…

> Catching is pretty similar no? In Go, you have to "catch" it at every call level. > Just to be clear, here we are talking about a function that already returns an exception/error and adding args to it Yes, but adding an arg doesn't mean modifying the error string, it means adding another piece of data which could be a different type. That's another var, and now every call level has to update to pass along that new…

> That’s another var

By another var, do you mean another return value? That’s not how it works in Go at all. It is possible to do it that way, but that would not be idiomatic.

You have a single error returned regardless of how many “errors” you have (> 0). If you need to return a new error and it is a custom struct that includes fields, you just implement Error interface on the struct and return it as the single error return. If you need to add new args on the struct, nothing changes other than the error implementation.

Do you want to return 2 errors from the same call site? You have to use something like multierror or a custom struct that includes 2 errors and implement the interface yourself. But the actual thing you return is still a single error.

> unless you want to change the var from string to map

Errors are not strings. It is an interface. If you want to return a string, you implement the interface (although it is much simpler to create a new error with errors.New). If you want to change it to a map later, you implement the interface on the map. It is transparent to the caller, because errors are dynamically dispatched the majority of the time.

> only if they need to handle it

Well, every function needs to declare which exceptions it throws, so you will have to modify every function in the call stack if you don’t want to handle it and it is a new type of Exception.

> That’s not the case in Go

That IS the case in Go. The most common pattern is to return an implementation of the error interface. Nothing changes if the underlying type of error changes except (potentially) the sites that want to handle a specific type of error.

Re: One year after switching from Java to Go

#462
post #318

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

That is actually enterprise culture, using Go won't make a difference in the enterprise space. Ever looked into Kubernetes source code?

I think Go adds to the enterprise culture and it does so on a global scale. Go is all about a consistent code style and a reduction of language complexity where your hands are tied on how you write code.

Re: One year after switching from Java to Go

#463
There are some arguements that were made in this post that don't matter at all.

One of those is: Cold start time

This isn't a big deal in the context of a web app. 8s vs 100ms. If you're scaling up a service. 8s is not a big deal in the scope of fixing a horizontal scaling issue.

Additionally, what it's considers bloat: Yes, you should optmize your app. It depends on the context of your application. Brining up a rest app that needs to stay up..who cares if it takes .5-1gb of ram.

Also, I didn't see it pointed out about the concerns of the lack of 3rd party frameworks. I find this disjointed and sparse frameworks to be more of a concern for a language/ecosystem than what the author pointed out.

Re: One year after switching from Java to Go

#464

Earlier quoted context omitted.

Disasters can be created in any language, right? Has little to do with Go.

True, but most of the arguments against java in this thread are similarly about bad dev practices and not the language itself.

Exactly.

Re: One year after switching from Java to Go

#465
post #284
post #246

Earlier quoted context omitted.

Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

You do realize that Java is objectively less verbose than Go? Even on a vanilla language to vanilla language basis, but let alone against something like Spring Boot that does almost everything for you in a typical CRUD application. Annotations are declerative shorthands . How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose? What about a single SQL query…

Annotations do many things.

Sometimes --in Spring Boot-- they hook different systems up with eachother: this makes the framework very "magic". I really dont like that: I want to be able to CTRL-click my way to understand how everything works!

Re: One year after switching from Java to Go

#466
post #246

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

Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

I think this is why most criticism of Java sounds weird to me. I've used Java since 1.3-ish and I've never used a web framework or an annotation and I think I've used a factory once (I think there's one in Swing and I recall thinking it was a stupid design choice).

Re: One year after switching from Java to Go

#467

Earlier quoted context omitted.

The big change is cultural. The places I've seen using .NET felt like cults to me, a monoculture were everyone must run windows, swearing by how powershell is the shell of the gods, ms sql being the only true data store that's the best solution for 100% of every use cases, azure being the best cloud provider, and everyone forced to use vs code because of all its fancy integration with even the pm tools.

What are the mythical .NET cults which swear by Windows, PowerShell and MSSQL you speak of? Every other ".NET shop" I know nowadays deploys to Linux hosts/container images hosted wherever and develops on a variety of systems where the OS of choice has become mostly a non-factor.

[deleted]

Re: One year after switching from Java to Go

#468
post #284

Earlier quoted context omitted.

You do realize that Java is objectively less verbose than Go? Even on a vanilla language to vanilla language basis, but let alone against something like Spring Boot that does almost everything for you in a typical CRUD application. Annotations are declerative shorthands . How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose? What about a single SQL query…

> You do realize that Java is objectively less verbose than Go? I might agree if you're speaking about Java since ~11 or so. One of my biggest complaints about Java, especially before the lambda syntax caught on, was how many extra files it made me create. I felt like every project had lots of wrapper classes, and people would make a make a file for each class. You could argue that that was "bad" Java and they should…

> which is something that I would have said would never happen if you had asked me five years ago.

I think a lot of people are noticing the changes Java has had in the previous years. The language has made a lot of improvements, and I feel that the mind set of the community has changed. The old enterprise way of factories and unnecessary abstractions have lost a lot of popularity, and is mostly still alive in legacy software/teams and universities who have not yet caught up.

Even Spring Boot is now a valid approach for getting sh*t done for startups. There are of course frameworks that are more light weight, or you can start from scratch and choose your own libraries to keep the size down. But SB is simply good enough for most use cases, and even supports native compilation now.

Re: One year after switching from Java to Go

#469

Earlier quoted context omitted.

> 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 th…

> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality people end up spending time messing around with config files and annotations.

> It sounds good but in reality people end up spending time messing around with config files and annotations.

I use Spring Boot at my day job and write mostly web services. I don't spend time messing around with config files and annotations. When I create a service class, I annotate it with @Service, and that is mostly what I need.

Example:

   @Service
   public record ItemsService(ItemsRepository repo) {

      public void doStuff(String country) {
         var items = repo.findByCountry(country);
         // do stuff with items
         
      }
   }
Later versions of Spring Boot has reduced a lot of the annotations necessary, like @Inject if you use constructors etc. There are of course other annotations and configurations, but 90% of what I do is similar to the example I gave above. Things may have changed since last you used it, but the amount of "magic" and annotations is often much less than what is posted in these types of discussions.

Re: One year after switching from Java to Go

#470

Earlier quoted context omitted.

> You do realize that Java is objectively less verbose than Go? I might agree if you're speaking about Java since ~11 or so. One of my biggest complaints about Java, especially before the lambda syntax caught on, was how many extra files it made me create. I felt like every project had lots of wrapper classes, and people would make a make a file for each class. You could argue that that was "bad" Java and they should…

> which is something that I would have said would never happen if you had asked me five years ago. I think a lot of people are noticing the changes Java has had in the previous years. The language has made a lot of improvements, and I feel that the mind set of the community has changed. The old enterprise way of factories and unnecessary abstractions have lost a lot of popularity, and is mostly still alive in legacy…

I still am not a huge fan of the Spring stuff, I have to use Spring Streams for work and I think it’s unpleasant to work with. It seems like the rest of the world has much more fun configuring YAML files than I do. I had to use Spring Boot at a previous job and it wasn’t for me, but honestly I really just hate working on web stuff.

But that’s obviously not the language’s fault. There are frameworks in Java that I think are great, like Vert.x; hell even going super low-level with NIO is straightforward enough if I really need control of HTTP stuff.

The stuff I really have the most fun working with is concurrent and distributed programs, and I think Java (or at least the JVM) is pretty hard to beat with that. Vert.x, Disruptor, and even the built-in JVM concurrency libraries (other than synchronized) are excellent; they have a Just Works quality to them.

And nowadays, GraalVM is good enough with its native compilation that you can avoid the long startup times and keep the memory under control, so it even is reasonably ok for custom command line tools.

Post reply on HN