• jim3692@discuss.online
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        2 days ago

        Can you elaborate? To me, Go seems to have less boilerplate.

        • Go does not have access modifiers
        • Go does not force you to put everything in classes
        • Go does not force you to put every exception, that may be thrown, at the function declaration
        • Go can directly map complex JSONs to structs
        • silasmariner@programming.dev
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          1 day ago

          In reverse order:

          • 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.

        • cub Gucci@lemmy.today
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 days ago

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

          1. 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.

          2. 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.

          3. 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.

          4. If err != nill. Don’t let me started on importance of result and either monads.

          5. 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.