3 ms·

So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what

So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what you and your team is most comfortable in. Avoiding allocations in Rust, on purpose, and being uncomfortable with how to solve design challenges caused by hyper optimizing your code .. is not a Rust problem. Or an any language problem. Rust gave you rope and you hung yourself with it. If you're stubborn and you want to use Rust but aren't familiar with the ways to avoid this; Allocate. Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. Some might reply "Well then why use Rust!?", to which i would reply because i like it! I love Rust, but if i'm prototyping code i'm not going to write insanely abstract generics either. Why would i? I don't know the problem i'm solving yet, so how can i write truly generic abstractions to solve said problems? Performance is similar. I'll use lifetimes will prototyping in the simple cases, which is most to be honest, but beyond that don't hyper optimize. To summarize: Choose your favorite language at crunch time. Even if your favorite language gives you rope to hang yourself with you probably don't need to.

dgb23 4y ago
> Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.
- maleldil 4y ago
  > It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust only forces you to be explicit when cloning, but memcpy is still a fast operation, unless you're cloning large structs.
  - 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 ago
      Really 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 ago
        Right, 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.

dgb23 4y ago

> Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.

maleldil 4y ago
> It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust only forces you to be explicit when cloning, but memcpy is still a fast operation, unless you're cloning large structs.
- 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 ago
    Really 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 ago
      Right, 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.