top | item 44883423

(no title)

leoqa | 6 months ago

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 abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc).

Regarding your IDE issues- I’ve found the new wave of copilot/cursor behavior to be the culprit. Sometimes I just disable it and use the agent if I want it to do something. But it’ll completely fail to suggest an auto complete for a method that absolutely exists.

discuss

order

treyd|6 months 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|6 months 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.

packetlost|6 months ago

Go discouraging abstracts is sorta just... wrong anyways. Go doesn't discourage building abstractions, it discourages building deep / layered abstractions.

Mawr|6 months 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?

jen20|6 months 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|6 months 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.