5 ms·

Personally I regard Rust as strictly less complex than most other languages (to use - not to learn). The space of programs you're searching through is smaller a

Personally I regard Rust as strictly less complex than most other languages (to use - not to learn). The space of programs you're searching through is smaller and more constrained (there are fewer valid Rust programs then valid Python programs, and we can make stronger statements about the behavior of a valid Rust program). Ergo, simpler. Internalizing those constraints so they aren't generally slowing you down takes an investment however. Recently I had a vexing silent bug in a prototype, where I was intermingling strings and ints as keys in a dictionary, and thus not writing to the correct keys. Normally I would be more careful than that, but it was a quick and dirty proof of concept. Because this involved JSON deserialization, Python's modest static type checking couldn't catch it. That just wouldn't have happened in Rust. (But of course, I wouldn't have had the particular ML libraries I needed, either, so Python remains the best option for this project.)

pharmakom 3y ago
There are infinitely many Rust and Python programs, just as there are infinitely many English sentences. Search is a really weird way to talk about programming.
- maxbond 3y ago
  I'm gunnuh address this because I think these are interesting nitty gritty details, but note that these are metaphors expressed in a shared vocabulary that happens to be technical, let's not get too caught up in how many Rust programs there are, that's a more literal interpretation than I intended. If you cap the number of tokens, the are fewer Rust programs. If you prefer, things that may be done implicitly in Python must be done explicitly in Rust - there are fewer valid choices when constructing a program; or equivalently, as you write a Python program, the options for your to proceed fan out faster. Really we aren't searching the whole space of programs though. We understand that adding no-ops to a program doesn't move us out of the equivalency class of that program (unless we're actually using those for timing or another side effect, of course, but then they are no-ops in name only). We're only searching through programs that reasonably solve the problem at hand. Maybe that space is infinite, I don't think so. I think of programming as being a fuzzy beam search (among other ways I sometimes think about programming). Your salience may vary, feel free to drop in a metaphor of your choosing there.
  - pharmakom 3y ago
    We can model programming as search, but programming as humans do it is more like design than search. I mean this in the qualitative and experiential sense. I don’t sit in front of the screen as candidate programs flash by until I see the one that I want. I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I really don’t see the possible program space as all that relevant.
    - maxbond 3y ago
      > I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I don't really see how else you would edit a program? That's what you're doing when you type at your IDE, right? But I think you're understanding how I think of it, feel free to take it or leave it. I'm not gunnuh die on a hill of insisting my way of thinking of it is right, it's just right for me. > I really don’t see the possible program space as all that relevant. In my example, I fell into a silently invalid state. In a more constrained environment, I wouldn't have. It's easier to go bowling with the bumpers turned on, and if your goal was to make as many strikes as possible (rather than to be sporting), surely you'd only ever bowl with the bumpers. It's a Murphy's law thing. The more invalid states you have, the easier it is to get mired there.
      - pharmakom 3y ago
        Most programmers (including myself) are editing unstructured text and after that text is written the editor will tell them if it’s valid code or not. Edit: I cannot reply, but there are structured program editors out there you may find interesting!
        maxbond 3y ago
        Yes, of course I do too, I live on the same planet, but that's an unstructured interface to changing the AST. (You can reply to comments when the reply button is hidden by clicking the link to go directly to the post. I consider it a polite request by dang to consider whether a conversation is getting too heated, which I don't think it is here at all. Cheers, I'll try to check those editors out.)
kaba0 3y ago
> The space of programs you're searching through is smaller and more constrained People don’t write programs by scanning through the space of possible ones, so I don’t see why would that not be a hindrance, let alone help one. Also, static types, or at least optional typing is at this point pretty much more common than dynamic typing, so I fail to see your example making Rust a better choice than “most other languages” for this reason. Especially that the real strictness of Rust is from the ownership system, which allows basically only tree-shaped lifetimes, and that’s not a restriction like a program being type-safe, where non-type safe programs don’t make sense. It is an “arbitrary” constraint that has obvious advantages for not memory-managed languages, but is absolutely not a tradeoff I would take when not necessary, as random lifetimes are just as valid.
- maxbond 3y ago
  > People don’t write programs by scanning through the space of possible ones I definitely search when I write programs. Do you write a program from start to finish and it works, or do you iterate and debug and sometimes find you've made a misstep & need to change your approach? Python's optional typing wasn't capable of spotting my issue, that was my point. Note I didn't say it was a better choice. I said, "strictly less complex." I wouldn't make a claim that Rust is "better." That only has meaning relative to a set of requirements. (Furthermore, I mentioned Python was a better choice for my project.) Tree shaped lifetimes are a very robust and easy to work with set of lifetimes. Of course you can add more degrees of freedom and write programs with graph lifetimes. That's fine, but it's pretty clearly more complex. I view allowing arbitrary lifetimes as something I don't want unless it's, well, absolutely necessary is too strong, but unless there's a compelling reason. It's not something I want to spend my complexity budget on, because it makes it more difficult to reason about and debug a program.
  - fauigerzigerk 3y ago
    >Of course you can add more degrees of freedom and write programs with graph lifetimes. That's fine, but it's pretty clearly more complex. How do you measure the complexity you're talking about here? What if a program using graph shaped lifetimes was 10 times shorter than a program that had to use tree shaped lifetimes? Would you still say that the tree shaped program is less complex?
formerly_proven 3y ago
I'd rephrase this as Rust enabling reasoning about program validity locally, while many other languages (regardless of type system, e.g. C, C++ and Python/Ruby/JS are typical examples) don't allow you to reason about program validity in localized increments. This promotes more modular designs, clearer interface boundaries and less "change anxiety".
- kaba0 3y ago
  > enabling reasoning about program validity locally About certain few properties only. It is impossible in the general case. I agree regarding “change anxiety” compared to dynamic languages, but that’s just static typing. Due to lifetime annotations leaking into API boundaries, the rest is not true though.

pharmakom 3y ago

There are infinitely many Rust and Python programs, just as there are infinitely many English sentences. Search is a really weird way to talk about programming.

maxbond 3y ago
I'm gunnuh address this because I think these are interesting nitty gritty details, but note that these are metaphors expressed in a shared vocabulary that happens to be technical, let's not get too caught up in how many Rust programs there are, that's a more literal interpretation than I intended. If you cap the number of tokens, the are fewer Rust programs. If you prefer, things that may be done implicitly in Python must be done explicitly in Rust - there are fewer valid choices when constructing a program; or equivalently, as you write a Python program, the options for your to proceed fan out faster. Really we aren't searching the whole space of programs though. We understand that adding no-ops to a program doesn't move us out of the equivalency class of that program (unless we're actually using those for timing or another side effect, of course, but then they are no-ops in name only). We're only searching through programs that reasonably solve the problem at hand. Maybe that space is infinite, I don't think so. I think of programming as being a fuzzy beam search (among other ways I sometimes think about programming). Your salience may vary, feel free to drop in a metaphor of your choosing there.
- pharmakom 3y ago
  We can model programming as search, but programming as humans do it is more like design than search. I mean this in the qualitative and experiential sense. I don’t sit in front of the screen as candidate programs flash by until I see the one that I want. I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I really don’t see the possible program space as all that relevant.
  - maxbond 3y ago
    > I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I don't really see how else you would edit a program? That's what you're doing when you type at your IDE, right? But I think you're understanding how I think of it, feel free to take it or leave it. I'm not gunnuh die on a hill of insisting my way of thinking of it is right, it's just right for me. > I really don’t see the possible program space as all that relevant. In my example, I fell into a silently invalid state. In a more constrained environment, I wouldn't have. It's easier to go bowling with the bumpers turned on, and if your goal was to make as many strikes as possible (rather than to be sporting), surely you'd only ever bowl with the bumpers. It's a Murphy's law thing. The more invalid states you have, the easier it is to get mired there.
    - pharmakom 3y ago
      Most programmers (including myself) are editing unstructured text and after that text is written the editor will tell them if it’s valid code or not. Edit: I cannot reply, but there are structured program editors out there you may find interesting!
      - maxbond 3y ago
        Yes, of course I do too, I live on the same planet, but that's an unstructured interface to changing the AST. (You can reply to comments when the reply button is hidden by clicking the link to go directly to the post. I consider it a polite request by dang to consider whether a conversation is getting too heated, which I don't think it is here at all. Cheers, I'll try to check those editors out.)

kaba0 3y ago

> The space of programs you're searching through is smaller and more constrained People don’t write programs by scanning through the space of possible ones, so I don’t see why would that not be a hindrance, let alone help one. Also, static types, or at least optional typing is at this point pretty much more common than dynamic typing, so I fail to see your example making Rust a better choice than “most other languages” for this reason. Especially that the real strictness of Rust is from the ownership system, which allows basically only tree-shaped lifetimes, and that’s not a restriction like a program being type-safe, where non-type safe programs don’t make sense. It is an “arbitrary” constraint that has obvious advantages for not memory-managed languages, but is absolutely not a tradeoff I would take when not necessary, as random lifetimes are just as valid.

maxbond 3y ago
> People don’t write programs by scanning through the space of possible ones I definitely search when I write programs. Do you write a program from start to finish and it works, or do you iterate and debug and sometimes find you've made a misstep & need to change your approach? Python's optional typing wasn't capable of spotting my issue, that was my point. Note I didn't say it was a better choice. I said, "strictly less complex." I wouldn't make a claim that Rust is "better." That only has meaning relative to a set of requirements. (Furthermore, I mentioned Python was a better choice for my project.) Tree shaped lifetimes are a very robust and easy to work with set of lifetimes. Of course you can add more degrees of freedom and write programs with graph lifetimes. That's fine, but it's pretty clearly more complex. I view allowing arbitrary lifetimes as something I don't want unless it's, well, absolutely necessary is too strong, but unless there's a compelling reason. It's not something I want to spend my complexity budget on, because it makes it more difficult to reason about and debug a program.
- fauigerzigerk 3y ago
  >Of course you can add more degrees of freedom and write programs with graph lifetimes. That's fine, but it's pretty clearly more complex. How do you measure the complexity you're talking about here? What if a program using graph shaped lifetimes was 10 times shorter than a program that had to use tree shaped lifetimes? Would you still say that the tree shaped program is less complex?

formerly_proven 3y ago

I'd rephrase this as Rust enabling reasoning about program validity locally, while many other languages (regardless of type system, e.g. C, C++ and Python/Ruby/JS are typical examples) don't allow you to reason about program validity in localized increments. This promotes more modular designs, clearer interface boundaries and less "change anxiety".

kaba0 3y ago
> enabling reasoning about program validity locally About certain few properties only. It is impossible in the general case. I agree regarding “change anxiety” compared to dynamic languages, but that’s just static typing. Due to lifetime annotations leaking into API boundaries, the rest is not true though.