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

• jim3692@discuss.online ⁨1⁩ ⁨day⁩ 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 ⁨18⁩ ⁨hours⁩ 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 ⁨1⁩ ⁨day⁩ 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