4 ms·

When I don’t like how something was done in a Go codebase, I’m generally SOL, since it was repeated so many times that there aren’t enough hours in the day to c

When I don’t like how something was done in a Go codebase, I’m generally SOL, since it was repeated so many times that there aren’t enough hours in the day to change them all. When extremely motivated, I’ll script manipulation of the AST, but that’s a pretty extreme thing to have to do.

candiodari 5y ago
Abstractions add a great deal of "default", potentially very complex, behaviour. This is great when starting a greenfield application. Even in extreme cases like RoR they work and quickly get a whole lot of things running. Fantastic. My newfangled thingamabob does something! And then the application grew and you have the guys who have to watch and keep the application online when it's business critical. They HATE abstractions. Because 7 abstractions that are used throughout the application means there's 127 cases the developer hasn't thought through, at least ten of them a ticking time bomb. That's 128 possible cases, one of which the developer has actually thought about, 5 they have verified to be reasonable. An easy case to show what's happening is the suggestion every new developer makes. "I'll just have a thread per connection, that's easy". And yes, it's very easy to get it running. It doesn't block during dev, it handles multiple connections and generally does the job. And it's absolutely guaranteed to crash you server for 10 different reasons in production. And yet, every new developer will (and should) do it. There's just 2 camps developers in the world, who don't agree and this won't seriously change. Learn how the "other camp" thinks and you'll do better.
- dnautics 5y ago
  I think you're confusing abstraction for framework.
adrianN 5y ago
Scripting manipulation of the AST is something that tooling can make much nicer. That might not exist (yet) for Go, but I think there is a lot of value in making the language easy to understand for tooling. Compare for example the quality of IDEs for Java vs C++. But this is of course orthogonal to generics, as you can make generics friendly to tooling as well, see Java.

candiodari 5y ago

Abstractions add a great deal of "default", potentially very complex, behaviour. This is great when starting a greenfield application. Even in extreme cases like RoR they work and quickly get a whole lot of things running. Fantastic. My newfangled thingamabob does something! And then the application grew and you have the guys who have to watch and keep the application online when it's business critical. They HATE abstractions. Because 7 abstractions that are used throughout the application means there's 127 cases the developer hasn't thought through, at least ten of them a ticking time bomb. That's 128 possible cases, one of which the developer has actually thought about, 5 they have verified to be reasonable. An easy case to show what's happening is the suggestion every new developer makes. "I'll just have a thread per connection, that's easy". And yes, it's very easy to get it running. It doesn't block during dev, it handles multiple connections and generally does the job. And it's absolutely guaranteed to crash you server for 10 different reasons in production. And yet, every new developer will (and should) do it. There's just 2 camps developers in the world, who don't agree and this won't seriously change. Learn how the "other camp" thinks and you'll do better.

dnautics 5y ago
I think you're confusing abstraction for framework.

adrianN 5y ago

Scripting manipulation of the AST is something that tooling can make much nicer. That might not exist (yet) for Go, but I think there is a lot of value in making the language easy to understand for tooling. Compare for example the quality of IDEs for Java vs C++. But this is of course orthogonal to generics, as you can make generics friendly to tooling as well, see Java.