3 ms·

Rust makes you think about your memory layout, memory allocation and avoiding thereof, about the specific time you grab and release other resources, about speci

by nine_k 2y ago

Rust makes you think about your memory layout, memory allocation and avoiding thereof, about the specific time you grab and release other resources, about specifics of your inter-thread interactions, etc. If such considerations are natural for your problem domain, you likely do "systems programming" and also happen know C, have an.opinion on Zig, etc. If such considerations are the noise which you wish your language would abstract away, then you likely do "application programming", and you can pick from a wide gamut of languages, from Ruby and Python to Typescript to Elixir and Pony to C#, Java, and Kotlin to OCaml and Haskell. You can be utterly productive with each.

sophacles 2y ago
What does "think about your memory layout" mean? Can you provide an example? I've seen this brought up a few times on this thread and have no idea what people are referring to when they say it. As for the rest of your list - I'm not sure why rust is special in regards to "the specific time you grab and release resources" or "inter-thread interactions". Seriously - I have to think about when I acquire and release resources like sockets and file handles python, c, ocaml, java, c#, and every other language I've used. Its not like you can randomly call file.close() or close(fd) (in python and c respectively) and expect to be able to continue reading or writing the file later. Same for inter-thread interactions... all those languages have mutexes too. Like none of that is rust-specific, its just the consequence of using resources and threads in code.
- tptacek 2y ago
  Again, the subtext here is GC versus direct control of memory lifecycles, and it is probably not reasonable to argue that there isn't a tradeoff here --- that every application is as gracefully expressible in one as the other, so long as you "git gud" at it. Both sides of this debate are guilty of deploying that trope.
  - sophacles 2y ago
    I'm not arguing that there isn't a tradeoff, or about "git gud". I'm literally and genuinely baffled about how one can magically elide knowing if a file is open or closed (or the equivalent) when using a resource. Like I can't think of a single language that doesn't make you explicitly obtain resources, and most of the GC languages do the same thing as rust for casual closing - just let the handle go out of scope. Even for memory, a huge amount of the rust I write isn't performance code - I don't understand why it's a mental burden to write let x = vec![a, b, c]; When the equivalent in python is: x = [a, b, c] Nothing about either requires a lick of memory allocation thought, nor about memory layout. Sure in rust I have to think about what I'm going to do with that vec in rust and the mutation story up-front, but after enough lines of python I have also learned to think of that up front there too (ortherwise I know I'm going to be chasing down how I ended up mutating a copy of the list rather than the original list I wanted to mutate - usually because someone did list = $list_comprehension somewhere in the call stack before mutating). I'm not being disingenuous here - I literally don't understand the difference, it feels like an oddly targetted complaint about things that are just what computer languages do. To the best of my ability to determine the biggest differences between the languages aren't about what's simple and complex, but how the problems with the complex things express themselves. I mean it's not like getting a recursion limit error in python on a line that merely does "temp = some_object.foo" is straight-forward to deal with, or the problems with "for _, x := range foo { func() { stuff with x } }" are easy to understand/learn to work with - but I don't see people running around saying you shouldn't learn those languages because there's a bunch of hidden stupid crap to wrap your head around to be effective. (and yes, i did run into both those problems in my first week of using the languages) In all the languages there are wierd idioms and rules - some of them you get used to and some of them you structure your program around. Sometimes you learn to love it, and sometimes it annoys you to no end. In every case I've ever found it's either learn to work with the language or sign up for a world of pain, but if you choose the former everything gets easier. When a language makes something seem hard, but it seems easy in my favorite language, well, in that case I've discovered the complexity is there in both, but when it's hidden from me it limited my ability to see a vast array of options to explore and shown a whole new set of problem solving tools at my disposal. I still don't know what people mean when they talk about "having to think about memory layout"... like seriously to me it's: Thinking about pointer alignment and how to cast one struct into another in C... something I've only had to think about once in any language across a fairly wide range of tasks. If this is what's being referred to, I'm baffled about how it's coming up so much, but i suspect this isn't what people mean, and I don't know what they actually do mean.
- nine_k 2y ago
  > What does "think about your memory layout" mean? Here are some of the typical concerns: - How exactly fields of a record sit in memory, how much room do hey take, taking into account things like padding for aligned access? - Are related data sit next to each other, and can stay in the CPU cache together while needed? - Are chaotic memory accesses thrashing the cache? - Do the data structures avoid gratuitous references / pointer chasing (at least mostly)? - Are local variables mostly allocated on the stack? - Does your code avoid heap allocations where possible? - Do fields in your data structure match a binary format, such as of an IP packet, or a memory-mapped register? - Are your sensitive data protected from paging out to disk if free RAM is exhausted? If these questions are not even relevant for your problem domain, you likely are not doing systems programming.

by nine_k 2y ago

sophacles 2y ago

What does "think about your memory layout" mean? Can you provide an example? I've seen this brought up a few times on this thread and have no idea what people are referring to when they say it. As for the rest of your list - I'm not sure why rust is special in regards to "the specific time you grab and release resources" or "inter-thread interactions". Seriously - I have to think about when I acquire and release resources like sockets and file handles python, c, ocaml, java, c#, and every other language I've used. Its not like you can randomly call file.close() or close(fd) (in python and c respectively) and expect to be able to continue reading or writing the file later. Same for inter-thread interactions... all those languages have mutexes too. Like none of that is rust-specific, its just the consequence of using resources and threads in code.

tptacek 2y ago
Again, the subtext here is GC versus direct control of memory lifecycles, and it is probably not reasonable to argue that there isn't a tradeoff here --- that every application is as gracefully expressible in one as the other, so long as you "git gud" at it. Both sides of this debate are guilty of deploying that trope.
- sophacles 2y ago
  I'm not arguing that there isn't a tradeoff, or about "git gud". I'm literally and genuinely baffled about how one can magically elide knowing if a file is open or closed (or the equivalent) when using a resource. Like I can't think of a single language that doesn't make you explicitly obtain resources, and most of the GC languages do the same thing as rust for casual closing - just let the handle go out of scope. Even for memory, a huge amount of the rust I write isn't performance code - I don't understand why it's a mental burden to write let x = vec![a, b, c]; When the equivalent in python is: x = [a, b, c] Nothing about either requires a lick of memory allocation thought, nor about memory layout. Sure in rust I have to think about what I'm going to do with that vec in rust and the mutation story up-front, but after enough lines of python I have also learned to think of that up front there too (ortherwise I know I'm going to be chasing down how I ended up mutating a copy of the list rather than the original list I wanted to mutate - usually because someone did list = $list_comprehension somewhere in the call stack before mutating). I'm not being disingenuous here - I literally don't understand the difference, it feels like an oddly targetted complaint about things that are just what computer languages do. To the best of my ability to determine the biggest differences between the languages aren't about what's simple and complex, but how the problems with the complex things express themselves. I mean it's not like getting a recursion limit error in python on a line that merely does "temp = some_object.foo" is straight-forward to deal with, or the problems with "for _, x := range foo { func() { stuff with x } }" are easy to understand/learn to work with - but I don't see people running around saying you shouldn't learn those languages because there's a bunch of hidden stupid crap to wrap your head around to be effective. (and yes, i did run into both those problems in my first week of using the languages) In all the languages there are wierd idioms and rules - some of them you get used to and some of them you structure your program around. Sometimes you learn to love it, and sometimes it annoys you to no end. In every case I've ever found it's either learn to work with the language or sign up for a world of pain, but if you choose the former everything gets easier. When a language makes something seem hard, but it seems easy in my favorite language, well, in that case I've discovered the complexity is there in both, but when it's hidden from me it limited my ability to see a vast array of options to explore and shown a whole new set of problem solving tools at my disposal. I still don't know what people mean when they talk about "having to think about memory layout"... like seriously to me it's: Thinking about pointer alignment and how to cast one struct into another in C... something I've only had to think about once in any language across a fairly wide range of tasks. If this is what's being referred to, I'm baffled about how it's coming up so much, but i suspect this isn't what people mean, and I don't know what they actually do mean.
nine_k 2y ago
> What does "think about your memory layout" mean? Here are some of the typical concerns: - How exactly fields of a record sit in memory, how much room do hey take, taking into account things like padding for aligned access? - Are related data sit next to each other, and can stay in the CPU cache together while needed? - Are chaotic memory accesses thrashing the cache? - Do the data structures avoid gratuitous references / pointer chasing (at least mostly)? - Are local variables mostly allocated on the stack? - Does your code avoid heap allocations where possible? - Do fields in your data structure match a binary format, such as of an IP packet, or a memory-mapped register? - Are your sensitive data protected from paging out to disk if free RAM is exhausted? If these questions are not even relevant for your problem domain, you likely are not doing systems programming.