5 ms·

I quite frankly will just read the code. Go generally discourages abstractions so any code you jump into is fairly straightforward (compared to a hierarchy of a

• treyd 1y ago
  > Go generally discourages abstractions so any code you jump into is fairly straightforward This is a really anti-intellectual take. All of software engineering is about building abstractions. Not having abstractions makes the structure less easy to understand because they're made implicit, and forces developers to repeat themselves and use brittle hacks. It's not a way to build robust or maintainable software.
  • bjt 1y ago
    Go does have plenty of abstractions. I think the more charitable interpretation is "Go generally discourages metaprogramming." Which I would agree with, and I think positively distinguishes it from most popular languages.
    • eru 1y ago
      Go mostly only have abstractions that the language designers put into the language. It is (mostly) hostile to users defining their own new abstractions. A case in point is that arrays and maps (and the 'make' function etc) were always generic, but as a user until fairly recently you couldn't define your own generic data structures and algorithms.
  • Mawr 1y ago
    Did you cherry pick that part of the sentence and ignored "(compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc)." on purpose or?
    • treyd 1y ago
      Yeah this is exactly the stuff that you'll have to reinvent yourself on an ad-hoc basis in any sufficiently large project. I would argue it's sorta related to Greenspun's tenth rule: https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule Of course, you'll probably retreat and say "Go is better for small projects", but every large project started as a small one, and it's really hard to justify rewriting a project in a new language in a business context.
      • samdoesnothing 1y ago
        You don't need a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring, etc for any project. If one decides to implement these techniques in an ad-hoc basis in Go to solve problems, that's more to do with trying to apply principles and techniques from other languages in Go.
  • packetlost 1y ago
    Go discouraging abstracts is sorta just... wrong anyways. Go doesn't discourage building abstractions, it discourages building deep / layered abstractions.
    • cryptos 1y ago
      That is a key point in my opinion. A typical stack trace of a Spring (Java) application can easily be 1000 to 2000 lines long. That is not so common in Go, as far as I know (I'm not a Go expert ...).
    • tcfhgj 1y ago
      Building abstractions and adding more layers goes hand in hand, e.g. see OSI layers. So GI indeed discourages abstractions.
      • packetlost 1y ago
        Not really, it's more like it encourages "wide" abstraction (lots of shallow abstractions) that get pieced together vs heavily nested abstractions that encapsulate other abstractions. It's a very imperative language.
  • deleted 1y ago
    [deleted]
  • jen20 1y ago
    Nor is Spring Boot with hidden implicit behaviour all over the show. Nor are AbstractProxyFactoryBeans, or IOC containers. Code you can read and understand linearly and end to end is hugely underrated.
• osigurdson 1y ago
  >> Go generally discourages... Really, there is nothing in the language that prevents you from creating crazy AbstractFactoryFactories or doing DI. What really prevents this is the community. In enterprise C# / Java, insanity is essentially mandated.