4 ms·
I think there is merit to these discussions. One has to ask what the most natural/idiomatic program to solve a problem is, and sometimes the performance of that
by conradludgate 4y ago
I think there is merit to these discussions. One has to ask what the most natural/idiomatic program to solve a problem is, and sometimes the performance of that matters more than the utmost performance you can get from the language.
I'm know to be a rust fanboy, so I'll talk about C++ instead. C++ is known to be fast, but theres also some known logic that you should use smart pointers to have more memory safety than raw pointers. If you follow that you'll end up with a slower program. Of course, you can remove those and manage the pointers yourself, but then you have to deal with documenting the lifetimes properly.
These are trade offs people agree to when using a language. The easier thing might be slower and that's ok. Speed isn't always critical, so you can't exactly rate languages by that metric alone
- spacechild1 4y ago> but theres also some known logic that you should use smart pointers to have more memory safety than raw pointers. If you follow that you'll end up with a slower program. That would be true for std::shared_ptr, but not for std::unique_ptr. You would/should only use the former if you're dealing with true shared ownership.