4 ms·
The early Go standard library (before it was hyper-optimized.)
by dchest 4y ago
The early Go standard library (before it was hyper-optimized.)
- blowski 4y agoThat's a fascinating observation. Do you think code inherently gets "worse" as it becomes more "optimised"?
- dchest 4y agoYes, as it becomes more complicated, catching more edge cases, it becomes less readable. On the other hand, as the compiler improved, some parts of it became more readable (e.g not manually unrolling loops, avoiding manual inlining, introducing bit-manipulation functions into the library instead of repeating them everywhere). Unfortunately, it's unavoidable — faster code is usually longer and more complicated.
- marginalia_nu 4y agoIf you plot difficulty to read against optimization, I'd expect to find a u-shape relation between the two. When code is easy to read, it's easy to find and clean up redundant operations, which naturally makes it faster. On the other end there's some optimizations that require dealing with lower abstraction levels and additional special cases.
- shp0ngle 4y agoThey still try to document all the optimisations very thoroughly.
- nemo1618 4y agoI can't understate how valuable it is for a new language's stdlib to be so well written and therefore an excellent reference for style, design, performance, documentation etc. in your own code. Every time you need to lookup how something in the stdlib works, you get more exposure to what good code ought to look like.