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

121–130 of 503 posts

Re: One year after switching from Java to Go

#121

Post by prein »

epolanski wrote: post #31
tymscar wrote: post #27

Earlier quoted context omitted.

Totally agree with you, but one point against doing what you mentioned is that you want to replicate your prod environment as much as possible in CI, to be able to catch bugs

From my experience this has been mostly painless, and yes, in CI you can obviously run against environments using the same stack as prod. It may help that I'm writing plain old boring ecommerces or internal tools (scrapers, chatbots, backoffices, warehouse management, delivery systems, etc) and not something more complex and low-level like databases or rendering engines.

Interesting idea, but I would worry that developers wouldn’t catch things like slow queries or other performance issues that crop up when using an actual database.

Re: One year after switching from Java to Go

#122

Post by amazingamazing »

jbhoot wrote: post #118
CharlieDigital wrote: post #43

Earlier quoted context omitted.

Even if your entire stack is TS, you still need validation because the submitted data from an external interface (API call) might not be valid. You can't just accept any JSON payload and expect it to be valid. In Java or .NET, it will fail at serialization when the runtime tries to map it to a static type (automatic). This is not the case at runtime with JS (because at runtime, it's no longer TS). Thus you need a Zod…

I think CharlieDigital's point is that a bad payload will fail right at the serialisation boundary in case of .NET. We know the problem right there. Now we only need to fix the bad payload. For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

Re: One year after switching from Java to Go

#123

Post by CharlieDigital »

hedora wrote: post #117
CharlieDigital wrote: post #60

Earlier quoted context omitted.

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…

Exceptions are fine if you never catch them. So is calling abort(). (Which is the Unix way to do what you described.) If you need to handle errors, you quickly get into extremely complicated control flow that you now have to test: // all functions can throw, return nil or not. // All require cleanup. try { a = f(); b = a.g(); } catch(e) { c = h(); } finally { if a cleanup_a() // can throw if b cleanup_b() // null che…

Can you give the equivalent in Go?

Re: One year after switching from Java to Go

#124

Post by nine_k »

MrDarcy wrote: post #25
bryancoxwell wrote: post #18

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

The exact stack trace may not be very necessary, but tracing the chain of calls, especially async, can be hugely helpful in troubleshooting, performance tracking, etc.

In Node, I remember wrapping Promisesromises into objects that had a stack for pushing messages onto them, so that the creator of a Promise could mark the calling site, and creating another Promise within that promise would pick up the chain of call site names and append to it, etc. Logging that chain when a Promise fails proved to be very useful.

Re: One year after switching from Java to Go

#125

Post by CharlieDigital »

amazingamazing wrote: post #122
jbhoot wrote: post #118

Earlier quoted context omitted.

I think CharlieDigital's point is that a bad payload will fail right at the serialisation boundary in case of .NET. We know the problem right there. Now we only need to fix the bad payload. For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

Here is a .NET web API

    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();

    app.MapGet("/{userId}", (int userId) => userId);
    app.Run();
See `int userId`? If I call this API with `http://localhost:5123/asdf`, I will get an error because the types don't match. If I call this with `http://localhost:5123/1234` it will work fine. The same would be true if I required a class `User` here. The router is able to introspect the type at runtime to determine if the types match; both basic types like this as well as complex types using the built-in serializer. It is built in.

I've put it into a short clip for you: https://imgur.com/a/WNbGUQD

Re: One year after switching from Java to Go

#126

Post by re-thc »

bdangubic wrote: post #86
computerdork wrote: post #65

Earlier 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 :)

> eight years later, there are still no good alternatives

Micronaut? Quarkus? Depends on what you need.

Re: One year after switching from Java to Go

#127

Post by amazingamazing »

CharlieDigital wrote: post #125
amazingamazing wrote: post #122

Earlier quoted context omitted.

Again this isn’t an inherent property of .net, you have to add validation. There are plenty of ways to do this in node so the point is moot.

Here is a .NET web API var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/{userId}", (int userId) => userId); app.Run(); See `int userId`? If I call this API with ` http://localhost:5123/asdf `, I will get an error because the types don't match. If I call this with ` http://localhost:5123/1234 ` it will work fine. The same would be true if I required a class `User` here. The rou…

I’m not sure why you’re so obsessed with this. You can do the same thing with any validation library in nodejs. Your exact example is possible by integrating any validation library of your choosing into a nest js route pipe. In particular primitive type validation is built into nestjs anyway

The fact that it’s built in is neat but not really important. Most people are not making thousands of toy apps. If the necessary they will integrate and move on.

There are more compelling reasons to use .net than this.

Re: One year after switching from Java to Go

#128

Post by re-thc »

tomohawk wrote: post #15
pseudoramble wrote: post #3

I’ve been out of the Java scene for a really long time, but will be coming back to it soon. I’m curious - these performance issues described here, are they inherit to how Java itself? Is it baggage from Spring/Boot? Are there ways to get more bang for the buck with some careful choices in a system like this? The closest I’ve done to Java recently is C#, which I think may have similar challenges, but overall didn’t se…

Having done a lot of Java and Go, Go has much better mechanical sympathy between the language, libraries, and vm than Java does. The JIT GC in Java are marvels of engineering, but they have to be. As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc. In Go, there is first class support for composition. The other main adjustment, if coming from Java, is…

> As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc

Strictly speaking that's not true. It's everything is a pointer in theory to make it easier to reason with and JIT / JVM optimizing in the background.

There are primitive types and there are lots of tricks in the JVM e.g. escape analysis that places objects on the heap/stack etc.

Re: One year after switching from Java to Go

#129

Post by owlstuffing »

dagss wrote: post #63
owlstuffing wrote: post #54

Going back to first principles, nominal typing is what I miss most with Go. I get the utility of structs + interfaces + structural typing, but most of the time there is more benefit in declaring that a type nominally implements an interface when that is the intention. Code is far easier to read and understand that way, both for developers and tooling. I suppose exclusively structural typing would be more acceptable i…

Are you aware of the trick of "var _ foo.RequiredInterface = myType{}" to make the compiler enforce that a struct implements a given interface? Is what you seek a nicer syntax for this or does what you speak of bring something more feature wise? At least IntelliJ IDEs will always make it clear what interfaces all your structs implement.

>Are you aware of the trick

Yes, and while it uses the compiler to ensure a type implements an interface, it's still a trick that exposes a large hole in the language... and begs for it to be filled. Most importantly, it still doesn't make the code much easier to read and understand.

>At least IntelliJ IDEs will always make it clear (or less foggy)

Indeed. Go benefits hugely from IntelliJ, or to be specific the IJ plugin API.

Re: One year after switching from Java to Go

#130

Post by 38 »

codr7 wrote: post #107
38 wrote: post #81

Earlier quoted context omitted.

https://github.com/codr7/tyred-java/tree/main/src/codr7/tyre... 24 of those files are under 100 lines - some of them are as small as three lines of code. and that's not a personal preference - that's mandated by Java that each type needs to be in its own file, ridiculous.

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
Post reply on HN