10 ms·
> Being fast isn't contradictory with this goal. If anything, this is a lesson that so many developers forget. Things should be fast by default. It absolutely
by pizza234 4y ago
> Being fast isn't contradictory with this goal. If anything, this is a lesson that so many developers forget. Things should be fast by default.
It absolutely is contradictory. If you look at the development of programming languages interpreters/VMs, after a certain point, improvements in speed become a matter of more complex algorithms and data structures.
Check out garbage collectors - it's true that Golang keeps a simple one, but other languages progressively increase its sophistication - think about Java or Ruby.
Or JITs, for example, which are the latest and greatest in terms of programming languages optimization; they are complicated beasts.
- atwood22 4y agoYes, you can spend a large amount of time making things faster. But note that Go's GC is fast, even though it is simple. It's not the fastest, but it is acceptably fast.
- YesThatTom2 4y agoFunny you should pick that example in a sub thread that you started with an assertion that code should be fast from by default. Go’s GC was intentionally slow at first. They wanted to get it right THEN make it fast. No offense but you’re not making a strong case. You’re sounding like an inexperienced coder that hasn’t yet learned that premature optimization is bad.
- atwood22 4y agoJust FYI, Go's GC mantra is "GC latency is an existential threat to Go."
- gpderetta 4y agoFar from it, Go was designed to be optimizable form the start. The GC was obviously not optimal, but the language semantics were such that the GC can be replaced with a better one with relatively minimal disruption. Of course one can't release optimal code from version one, that would be absurd. Also your last sentence is extremely condescending.