31 ms·
As I said: It depends what you are writing. If you write big libraries and major codebases that are meant to represent the foundation for something big, maybe y
by atoav 4y ago
As I said: It depends what you are writing. If you write big libraries and major codebases that are meant to represent the foundation for something big, maybe you should not follow my advice. If however you are writing a small tool where good enough is indeed good enough (and still 10 times faster than equivalent python code), who cares.
Rust can go anywhere inbetween counting every bit and byte and doing no such thing at all. My point was that counting every bit will probably be not be the way 90% of the programs will be written if they are written in Rust (mostly due to the fact that programming in such a way is both much harder and takes longer — independent of the programming language).
So if someone who does not count bits programs a software in a field where it would be paramount to do precisely that, then this is not the fault of the programming language, but the fault of that person, their organisation or whatever.
- cyber_kinetist 4y agoThe thing is that languages like C++ or Rust has the potential to become something even slower than Python if you don’t know what you’re doing. For example, (the example is C++ but you can say the same thing about Rust): https://stackoverflow.com/questions/9378500/why-is-splitting-a-string-slower-in-c-than-python https://stackoverflow.com/questions/9378500/why-is-splitting... Same with smart pointers: Languages like Java and C# have highly tuned garbage collectors that can be faster than reference counting in most situations. The rationale mostly deployed for using RC isn’t simply just raw performance (it can be slower because of the refcount read/write for every dereference), but predictable performance (you don’t need to worry about GC lag spikes, which is important for real-time applications. But even that advantage seems to be disputed.)