2 ms·
Yes, go seems to come from a mentality that “excess abstraction is evil” where “excess abstraction” is defined as “any pattern enabled by a language feature dev
by stouset 8y ago
Yes, go seems to come from a mentality that “excess abstraction is evil” where “excess abstraction” is defined as “any pattern enabled by a language feature developed since the ‘80s”.
It’s madness. When writing application software in any language, you’re already umpteen levels of abstraction away from what’s really happening under the hood. You call a library that calls a library that calls another library over FFI that itself dynamically links to a function written in another language that’s all compiled down to object code that runs in little tiny timeslices chosen by a scheduler in an operating system that abstracts away the hardware running on a CPU that actually rewrites instructions using microcode to actually run on an internal RISC core but one more level of abstraction on top of all this is apparently where everything will go wrong.