4 ms·

> Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day. … which is how we got slow, bloated legacy C++ codebases today, sho

> Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day. … which is how we got slow, bloated legacy C++ codebases today, should we make the same mistake with Rust? If you are wrapping everything in ref-counted smart pointers it might probably be better to just use a garbage-collected language like Java or C# instead…

KptMarchewa 4y ago
It's an giant exaggeration to blame "slow, bloated legacy C++ codebases today" on smart pointers.
- deleted 4y ago
  [deleted]
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 ago
  The 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.)

KptMarchewa 4y ago

It's an giant exaggeration to blame "slow, bloated legacy C++ codebases today" on smart pointers.

deleted 4y ago
[deleted]

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 ago
The 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.)