3 ms·
> your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java Python very likely, Node probably too, not sure. I doubt it's true f
by dgb23 4y ago
> your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java
Python very likely, Node probably too, not sure. I doubt it's true for the others. My guess is you're going to use less resources (memory etc.) but you're not going to beat their runtimes with hand-rolled GC (ref counting) and allocations all over the place.
- unshavedyak 4y agoReally depends on what you're doing. The thing is if you know enough about why cloning is slow - like a really fat string or a tight loop - you probably also know enough to avoid that. At least in my experience. There's a ton of rope in Rust with lifetimes, generics, etc. Most if not all generic bounds have implications about the user and caller. Choosing which type of methods you use to avoid allocation while prototyping can be exceptionally difficult to do and be correct. Refcounting is not that bad imo, and is very very easy. The moment you're at "well we need to beat the performance of X" is probably when you can make better/intelligent decisions about how you allocate, whether to use Arena/Bump/etc. Also, if you wanted to be in Go/C#/etc you just would. You're using Rust (in this discussion) because you wanted to. When performance is a concern, you can deal with it - but the basic allocation tricks (Arc/etc) don't represent such a significant performance loss that suddenly your Prototype no longer functions.
- dgb23 4y agoRight, I missed the broader point. When you choose to use Rust but need to advance quickly, you are going to be fine with some of these techniques.