3 ms·
> That is one of the drivers of the recent growth in compiled languages (Rust, Go, ...), Not the only one but it helped. No, not really. In either case (rust,
by nuerow 5y ago
> That is one of the drivers of the recent growth in compiled languages (Rust, Go, ...), Not the only one but it helped.
No, not really. In either case (rust, Go) perfomance is at best a nice-to-have, while their main value proposition is, and has always been, turnaround time and consequently man*hours. Rust is marketed primarily due to their first-class support for safe programming constructs, and providing a far better developer experience over C and C++ at the expense of a small but negligible performance impact. Go is marketed primarily for it's first-class support for concurrency, and provide a far better developer experience than Java, C#, and C++ with little to no performance gains at all.
What matters is how long it takes developers to add value. That's it. Most of the times there is simply no value to be gained by shaving a megabyte or millisecond here or there, but undoubtedly there is value in shipping features, not having downtime, and eliminating bugs.
- Chris_Newton 5y agoIt seems that your argument throughout this discussion is based on two assumptions. (1) Software already has acceptable performance. (2) Further work to improve its performance is likely to have large development costs but deliver only small benefits. I’m not sure either of those assumptions is safe. As the early parts of the lecture we’re discussing today demonstrated, sometimes there are dramatic performance improvements that can be made if you know what you’re doing and they can make a similarly dramatic difference to how beneficial the software is to its users.