2 ms·
i agree that in typical business situations often the main constraints to solve for aren't squeezing the most compute out of a CPU, it's rarely the bottleneck (
by shoo 3y ago
i agree that in typical business situations often the main constraints to solve for aren't squeezing the most compute out of a CPU, it's rarely the bottleneck (although of course some people can no doubt chime in from contexts where compute is frequently the bottleneck and what they spend most of their time fretting about).
good engineering should figure out what the main constraints are, and solve for those, while doing a "good enough" job for everything else and no more -- like you allude to, the main bottlenecks to solve for are usually things like reducing engineering effort, reducing schedule, reducing long term maintenance cost of the overall system (not just this isolated component) - especially how easy it is to hire someone who can understand and fix the thing.
but, this article isn't a "how to make good whole-system engineering tradeoffs for the long-term benefit or your employer / client" article, it's an article showing how to write fast rust code.
- refactor_master 3y ago> but, this article isn't a "how to make good whole-system engineering tradeoffs for the long-term benefit or your employer / client" article, it's an article showing how to write fast rust code. As you can probably tell from my sentiment above, it doesn’t help the author’s cause by basing the premise on a strawman. If the intention was to push Rust for Python users, this article shoots far, really far, but completely misses the mark. Nobody was telling themselves that Python was the fastest language out there.