Directly mapping structs to JSON is a solved problem in userland for every major language
yes it does, and worse it’s part of the return signature and null is super-prevalent of necessity as a result
even java doesn’t do that any more, but fine I guess
cool, but access modifiers actually make a lot of sense. Go’s solution to this is to use capitalisation as a marker, which has no ‘inferential readability’ – public/private is obvious. Foo/foo? Considerably less so
Further, meta programming in go sucks donkey balls. Sure, it finally got generics but also they suck. Last I checked it still didn’t even support covariance.
Yeah, Go is nice sometimes. It shines in codebases that are not quite large and not very small. Also it’s great to write a cli tool in it, though I prefer Rust because I hate myself. What I personally missed in Go (maybe skill issue, idk):
Metaprogramming. For big projects it’s inevitable. You need to have SPOT which generates documentation and headers (e.g. xml document, openapi spec). Otherwise you die. The fact that the source should be a git repo is cancer, as in this case artifacts are added in git, which results in merge conflicts.
DI. In JVM world it is a must. If you don’t have it, you fucking should have a reason for that! If your logic spans across multiple layers of factories, onboarding of a new developer creates friction.
For small web services that are not constrained by memory I would choose spring + openapi, as it really requires only model description and the endpoint, yielding you a client in any language you want.
If err != nill. Don’t let me started on importance of result and either monads.
Aspects and (usable) reflection. I want a codebase that has actual decoupling. I want a security code to be in a completely different place, away from the business logic, just as I want traces with serialization to be pluggable I don’t want to have a single place in code that has a sequence auth -> validate inputs -> trace -> business logic -> validate output. I strongly believe that it’s faulty, untestable and prone to errors.
Can you elaborate? To me, Go seems to have less boilerplate.
In reverse order:
Further, meta programming in go sucks donkey balls. Sure, it finally got generics but also they suck. Last I checked it still didn’t even support covariance.
Yeah, Go is nice sometimes. It shines in codebases that are not quite large and not very small. Also it’s great to write a cli tool in it, though I prefer Rust because I hate myself. What I personally missed in Go (maybe skill issue, idk):
Metaprogramming. For big projects it’s inevitable. You need to have SPOT which generates documentation and headers (e.g. xml document, openapi spec). Otherwise you die. The fact that the source should be a git repo is cancer, as in this case artifacts are added in git, which results in merge conflicts.
DI. In JVM world it is a must. If you don’t have it, you fucking should have a reason for that! If your logic spans across multiple layers of factories, onboarding of a new developer creates friction.
For small web services that are not constrained by memory I would choose spring + openapi, as it really requires only model description and the endpoint, yielding you a client in any language you want.
If err != nill. Don’t let me started on importance of result and either monads.
Aspects and (usable) reflection. I want a codebase that has actual decoupling. I want a security code to be in a completely different place, away from the business logic, just as I want traces with serialization to be pluggable I don’t want to have a single place in code that has a sequence
auth -> validate inputs -> trace -> business logic -> validate output. I strongly believe that it’s faulty, untestable and prone to errors.