3 ms·

> I still don't know what people mean when they talk about "having to think about memory layout" The best example I'd give is the degree to which you have to a

> I still don't know what people mean when they talk about "having to think about memory layout" The best example I'd give is the degree to which you have to ask yourself if you want to use String or if you want to use &str--is this struct, or this function, going to own the string or borrow it from somebody else? If you're borrowing it, who is owning it? Can you actually make that work (this is really salient for parser designs)? Essentially in Rust, before you can really start on a large project, you have to sit down and plan out how the memory ownership is going to go, and this design work doesn't really exist in most other languages. Note that it's not inherently a good thing or a bad thing, but it is a potential source of friction (especially for small projects or exploratory tools where memory ownership might want to evolve as you figure out what needs to happen).

tptacek 2y ago
Wading in here a little bit, and I know you've thought about this --- I think it's reasonable to say that there are problem domains where it's a very good thing, and problem domains where it isn't. I think a subtextual problem for Rust advocacy is that the places where it's a clear win are a small subset of all software problems, and that space is shrinking. Rust would, in that view of the world, be a victim of its success: it's the best replacement we have for C/C++ today, but the industry has moved sharply away from solving problems that way, and sharply towards solving them with Javascript. (Deno is doing something smart here.)
dvektor 2y ago
The way memory allocation and management becomes part of the paradigm of how we write and structure programs, is actually something I really enjoy about rust. It's like how you can do the exact same thing in C++, using the same concepts and tools (for the most part) with different names, but it never felt the same, or as natural. It's definitely helped the way I think about programs as a whole.
- tptacek 2y ago
  I feel the same way when I implement reference counting in a C program. It's certainly clarifying and educational. I think it's hard to argue that it's the most expedient way to write a CRUD application, though. Sometimes the most expedient path isn't the most fun one.
steveklabnik 2y ago
> the degree to which you have to ask yourself if you want to use String or if you want to use &str In practice, there isn’t a ton of thinking to do about this: if it’s a struct, you want String. If it’s a function parameter, you want &str, and if it’s a function’s return type, you want String. Doing that until you have a reason not to is the right call 95% of the time, and 4% of that last 5% is “if the return type is derived from an argument and isn’t changed by the body, return &str. It does take some time when you’re learning, but once you get over the hump, you just don’t actively think about this stuff very much. Google’s research says Rust is roughly as productive as any other language there, so far. That doesn’t mean it’s universally true, but it’s also some evidence it’s not universally false.
- School-Cotton 2y ago
  If you write Rust like this (insisting that structs always fulfill 'static) you will end up unnecessarily cloning memory way more than you would in a GC'ed language. In GCed languages strings get allocated once when you need them, get referred to wherever you want, however many times you want (with no new calls to the allocation subsystem), and are freed once when you don't need them anymore, with minimal thought or intervention on the programmers part. Rust is absolutely not like this at all. I agree with the overall idea that people exaggerate the difficulty of Rust, but come on, this is an exaggeration way too far in the other direction.
  - steveklabnik 2y ago
    That’s why it’s “until proven otherwise.” As you gain experience you can be more subtle about it, and you gain more intuition, but it’s just not that big a deal until you demonstrate it’s a big deal. I rarely type clone(). Even with this advice, you won’t clone super often. And when you do, it’s a signal sometimes that maybe you can do better, but it’s just not a big cognative burden.
- rc00 2y ago
  > Google’s research says Rust is roughly as productive as any other language there, so far. That doesn’t mean it’s universally true, but it’s also some evidence it’s not universally false. You shouldn't call this evidence but instead marketing. It was thoroughly debunked for the nonsense that it was in many places such as this: https://www.youtube.com/watch?v=vB3ACXSesGo https://www.youtube.com/watch?v=vB3ACXSesGo

tptacek 2y ago

Wading in here a little bit, and I know you've thought about this --- I think it's reasonable to say that there are problem domains where it's a very good thing, and problem domains where it isn't. I think a subtextual problem for Rust advocacy is that the places where it's a clear win are a small subset of all software problems, and that space is shrinking. Rust would, in that view of the world, be a victim of its success: it's the best replacement we have for C/C++ today, but the industry has moved sharply away from solving problems that way, and sharply towards solving them with Javascript. (Deno is doing something smart here.)

dvektor 2y ago

The way memory allocation and management becomes part of the paradigm of how we write and structure programs, is actually something I really enjoy about rust. It's like how you can do the exact same thing in C++, using the same concepts and tools (for the most part) with different names, but it never felt the same, or as natural. It's definitely helped the way I think about programs as a whole.

tptacek 2y ago
I feel the same way when I implement reference counting in a C program. It's certainly clarifying and educational. I think it's hard to argue that it's the most expedient way to write a CRUD application, though. Sometimes the most expedient path isn't the most fun one.

steveklabnik 2y ago

> the degree to which you have to ask yourself if you want to use String or if you want to use &str In practice, there isn’t a ton of thinking to do about this: if it’s a struct, you want String. If it’s a function parameter, you want &str, and if it’s a function’s return type, you want String. Doing that until you have a reason not to is the right call 95% of the time, and 4% of that last 5% is “if the return type is derived from an argument and isn’t changed by the body, return &str. It does take some time when you’re learning, but once you get over the hump, you just don’t actively think about this stuff very much. Google’s research says Rust is roughly as productive as any other language there, so far. That doesn’t mean it’s universally true, but it’s also some evidence it’s not universally false.

School-Cotton 2y ago
If you write Rust like this (insisting that structs always fulfill 'static) you will end up unnecessarily cloning memory way more than you would in a GC'ed language. In GCed languages strings get allocated once when you need them, get referred to wherever you want, however many times you want (with no new calls to the allocation subsystem), and are freed once when you don't need them anymore, with minimal thought or intervention on the programmers part. Rust is absolutely not like this at all. I agree with the overall idea that people exaggerate the difficulty of Rust, but come on, this is an exaggeration way too far in the other direction.
- steveklabnik 2y ago
  That’s why it’s “until proven otherwise.” As you gain experience you can be more subtle about it, and you gain more intuition, but it’s just not that big a deal until you demonstrate it’s a big deal. I rarely type clone(). Even with this advice, you won’t clone super often. And when you do, it’s a signal sometimes that maybe you can do better, but it’s just not a big cognative burden.
rc00 2y ago
> Google’s research says Rust is roughly as productive as any other language there, so far. That doesn’t mean it’s universally true, but it’s also some evidence it’s not universally false. You shouldn't call this evidence but instead marketing. It was thoroughly debunked for the nonsense that it was in many places such as this: https://www.youtube.com/watch?v=vB3ACXSesGo https://www.youtube.com/watch?v=vB3ACXSesGo