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

41–50 of 503 posts

Re: One year after switching from Java to Go

#41

Post by MrDarcy »

epolanski wrote: post #26

Very ignorant about Go, is dependency injection not a thing there? E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them. I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted…

DI is generally not an explicit thing in Go. As a sibling comment mentioned, there is wire but it simply generates code, it is not a runtime DI framework like Spring has. This is a feature. The code wire generates is the same code you’d normally write, which is what makes it unnecessary for many projects.

Go has interfaces natively which are implemented in a different way. We never need to say X implements I like we do in other languages. X either satisfies the interface or it doesn’t and the compiler and editor catch this fact early.

So, you’d simply declare an interface to define the API you described in Go, no need for DI or anything else.

Re: One year after switching from Java to Go

#42

Post by jamesfinlayson »

xxs wrote: post #16
jamesfinlayson wrote: post #8

Earlier quoted context omitted.

> most of it is just startup Yep, I have some Spring code in AWS ECS and it hits 100% CPU usage on start-up before dropping back to 1.5% when idling (this is with 1 vCPU I think). But yeah I remember reading one of the Spring devs say that some (a lot?) of the runtime reflection could be done at compile time but isn't.

> Spring devs say that some (a lot?) of the runtime reflection It's a lot more than reflection, if it'd have been reflection alone - it'd be markedly better. (and yes, lots and lots can be optimized). Spring effectively: scans the classpath for resources - that includes jars, file system loads every single class matching the scanned directories as a byte array parses it in java (not by JVM) to check what annotations…

Ah okay - yeah I'm not across the internals at all.

And yeah I assume it's a single core, but definitely a heavy start.

Re: One year after switching from Java to Go

#43

Post by CharlieDigital »

amazingamazing wrote: post #39
CharlieDigital wrote: post #34

Earlier quoted context omitted.

Big problems for APIs though because TS types disappear at runtime. So now you need to add in Zod or Valibot as well to validate your types. If you have view models and DTOs, then you add more Zod. Might as well use a statically typed language? Working with OpenAPI is much easier when you already have a static type system. How about database transactions? Ran into an interesting issue this week. In a .NET world, ever…

> How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing. I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.

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 or a Valibot to ensure the incoming payload is actually valid by describing the valid types (even if your whole stack is TS at dev time because schema mismatches are a runtime problem).

.NETs System.Text.Json does the mapping and validation using either reflection or AOT generated serializers transparently and automatically because it has static types.

Re: One year after switching from Java to Go

#44

Post by arnath »

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…

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?

Re: One year after switching from Java to Go

#45

Post by amazingamazing »

CharlieDigital wrote: post #43
amazingamazing wrote: post #39

Earlier quoted context omitted.

> How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing. I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.

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…

Yes .NET's built in SDK is larger than Node.JS's. I'm not sure what your point is exactly. As you stated just use a validation library if that's necessary. It generally is not though, you can cast the entire output to a type in TypeScript, of course this isn't validation, but it's generally good enough.

Of course if you’re writing a full stack app you can share everything, validating the front and backend with the same code. Clearly that would be a strange thing to hold against .net, similar to the lack of built in validation in typescript.

Re: One year after switching from Java to Go

#46

Post by CharlieDigital »

amazingamazing wrote: post #45
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…

Yes .NET's built in SDK is larger than Node.JS's. I'm not sure what your point is exactly. As you stated just use a validation library if that's necessary. It generally is not though, you can cast the entire output to a type in TypeScript, of course this isn't validation, but it's generally good enough. Of course if you’re writing a full stack app you can share everything, validating the front and backend with the sa…

You double up your work. What you really wanted all along are static types.

Re: One year after switching from Java to Go

#47

Post by Ferret7446 »

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…

Context is just thread local storage aka dynamic scoping aka global variables.

It is useful for some things, particularly middleware that needs to cross API boundaries.

https://www.felesatra.moe/blog/2019/12/01/transiting-apis

Re: One year after switching from Java to Go

#49

Post by amazingamazing »

CharlieDigital wrote: post #46
amazingamazing wrote: post #45

Earlier quoted context omitted.

Yes .NET's built in SDK is larger than Node.JS's. I'm not sure what your point is exactly. As you stated just use a validation library if that's necessary. It generally is not though, you can cast the entire output to a type in TypeScript, of course this isn't validation, but it's generally good enough. Of course if you’re writing a full stack app you can share everything, validating the front and backend with the sa…

You double up your work. What you really wanted all along are static types.

not necessarily, and in plenty of programming languages static types do not give you validation for free, and in the case of .net you still have to call something else. it's no different than just using zod, other than the fact that it's built in.

if you're using typescript in the front end, seems double to even bother to introduce .net, when typescript and node is fine for the backend too.

Re: One year after switching from Java to Go

#50

Post by bob1029 »

epolanski wrote: post #26

Very ignorant about Go, is dependency injection not a thing there? E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them. I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted…

DI at its most fundamental interpretation is the act of passing (injecting) arguments (dependencies) to functions.

Nothing stopping you from doing function-level "injection" of generic or interface type arguments. In this context, function could include the ctor.

Post reply on HN