Comment on F*** You! Co-Creator of Go Language is Rightly Furious Over This Appreciation Email

• vivalapivo@lemmy.today ⁨2⁩ ⁨days⁩ ago

  I have. Go is verbose

  source

  • jim3692@discuss.online ⁨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 declare every exception that may be thrown by a function

    source

    • silasmariner@programming.dev ⁨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 or 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.

      source
    • vivalapivo@lemmy.today ⁨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.

      source