3 ms·

Sure. It might apply more though, with the cost/benefit analysis strongly favoring fast actions rather than good actions for high-paid professionals too. We hav

by hansvm 2y ago

Sure. It might apply more though, with the cost/benefit analysis strongly favoring fast actions rather than good actions for high-paid professionals too. We have some data suggesting e-waste is a problem. Maybe it's 10% in that demographic. That's still a 10k computers in the dump, purely because of slow Rust and C++ compile times, even if only 1% of people upgraded because of compile times and 10% of that demographic aren't responsible with their devices. It's also (very roughly) 1.3 million kwh per year extra for rust and cpp developers to use those slower compilers once a month, relative to faster alternatives. A few core maintainers have the power to fix that and have chosen not to. And maybe that's fine. But it's a real cost, quite large relative to the other impact those individuals might have, and it's worth acknowledging rather than dismissing.

fluoridation 2y ago
>It's also (very roughly) 1.3 million kwh per year extra for rust and cpp developers to use those slower compilers once a month, relative to faster alternatives. What do you mean by "faster alternatives"? There is only one Rust compiler, and all the C++ compilers are about equally fast. Do you mean languages that compile faster? Do you really think most projects can just be made in one language or another and it doesn't matter? >A few core maintainers have the power to fix that and have chosen not to. Nobody chooses to make inefficient software. First, there's only so many man-months in the month. Second, compilers are constantly evolving creatures. Optimizations, generally speaking, make software more difficult to maintain. What would you rather? A somewhat slow compiler that can optimize your code really well, or a compiler that runs really fast, but can only compile the language version from ten years ago and generates slow binaries because the maintainers can't work around the optimization redesign from fifteen years ago? >And maybe that's fine. But it's a real cost, quite large relative to the other impact those individuals might have, and it's worth acknowledging rather than dismissing. I think you're underestimating how complex modern compilers are. If people are dismissing your concerns it's because they understand that the price they pay for efficient programs is slow compilers.

by hansvm 2y ago

fluoridation 2y ago

>It's also (very roughly) 1.3 million kwh per year extra for rust and cpp developers to use those slower compilers once a month, relative to faster alternatives. What do you mean by "faster alternatives"? There is only one Rust compiler, and all the C++ compilers are about equally fast. Do you mean languages that compile faster? Do you really think most projects can just be made in one language or another and it doesn't matter? >A few core maintainers have the power to fix that and have chosen not to. Nobody chooses to make inefficient software. First, there's only so many man-months in the month. Second, compilers are constantly evolving creatures. Optimizations, generally speaking, make software more difficult to maintain. What would you rather? A somewhat slow compiler that can optimize your code really well, or a compiler that runs really fast, but can only compile the language version from ten years ago and generates slow binaries because the maintainers can't work around the optimization redesign from fifteen years ago? >And maybe that's fine. But it's a real cost, quite large relative to the other impact those individuals might have, and it's worth acknowledging rather than dismissing. I think you're underestimating how complex modern compilers are. If people are dismissing your concerns it's because they understand that the price they pay for efficient programs is slow compilers.