4 ms·

I think your idea of what Pythonic Rust might be goes against one of Rusts goals: not having hidden, costly abstractions, and instead giving the developer expli

I think your idea of what Pythonic Rust might be goes against one of Rusts goals: not having hidden, costly abstractions, and instead giving the developer explicit control. If you don't feel you need control over when data is copied, when there should be a mutex, atomic reference counting, and so on, you're probably reaching for the wrong language. IMO giving us explicit control of low level behavior is not a detriment to ergonomics as much as it is a benefit. Add in the package manager and great compiler and it feels like first class dev experience to me.

deleted 4y ago
[deleted]
convolvatron 4y ago
I'm a low level programmer, and programming in rust feels exactly like someone is taking the control I need to do my job away from me. maybe I'm wrong, and I can get it back by reverse engineering the whole stack and getting underneath things like tokio.
- JohnFen 4y ago
  As a Rust newbie, here's a chance for my understanding to be corrected, but... Isn't taking control away from the programmer the entire point of Rust? I thought the premise of it is that programmers can't be trusted. That sounds like a criticism, but I don't mean it as such. It's just what I hear when I hear people talking about the value of Rust. Is my understanding incorrect?
  - convolvatron 4y ago
    no. I don't think you're wrong. I was just adding a counterpoint to the above. as an old lisp programmer I really think systems should be less opaque. make things accessible and simple and useful, but make it easy to keep unwrapping. rust disturbs that journey by #deriving over the underlying truth to make things simple. but when you have to crack that open its a lot stuff to digest. I don't think rust is _wrong_, I just think that value statement you just made should be more explicit. and maybe rust devotees shouldn't be so quick to tell you that your high level goal is incorrect because its something rust doesn't handle well.
  - Measter 4y ago
    I would disagree. Rust's borrow checker and other static analysis are more akin to the safety guards on a table saw. For 95% of situations they're just protect you by catching your mistakes, but there are times when the guard makes it hard or impossible to do what you need to. In those situations, if you really need to do the work, you take the guards off for that work (unsafe would be the Rust equivalent), then put them back on afterwards.
    - steveklabnik 4y ago
      You’re totally right. I often cite https://www.sawstop.com/ https://www.sawstop.com/ as an even deeper analogy, in my opinion!
    - JohnFen 4y ago
      Huh. I think perhaps I was thinking a bit wrong about "unsafe". My take on it was that it's a kind of cheating and its use would be disallowed in commercial production environments. At least, it seems to get badmouthed a lot.
      - convolvatron 4y ago
        maybe unsafe rust is pretty ok to work in. as you say, I've never been in a shop where that was allowed
      - steveklabnik 4y ago
        > its use would be disallowed in commercial production environments. Working in embedded, completely banning unsafe would be impossible. Minimizing it is a good thing, generally. But it's there to be used.
  - steveklabnik 4y ago
    > Isn't taking control away from the programmer the entire point of Rust? Not in my perspective. It is about managing complexity. Rust allows you to take that "ultimate control," and then wrap it up in an easier to use package that doesn't have sharp edges. There is nothing you can't do in Rust if you want to. Heck, inline assembly is an actual part of the language, unlike in C and C++, where they're both vendor extensions!
    - JohnFen 4y ago
      > then wrap it up in an easier to use package I can't wait until I can start to see how anything about Rust is "easier to use". It's a slog for me right now, and I usually pick up new languages pretty easily. Again, not criticizing Rust. I'm taking the blame for my struggles myself.
      - steveklabnik 4y ago
        In this context, I'm not talking about usability in a general sense, I'm talking about "You don't need to consider if you're invoking UB with safe functions, unlike with unsafe functions, because the compiler checks things for you, so the number of considerations is smaller." You're right that maybe given that "easier" can mean many things to many people, I should have maybe chosen a different words. > I'm taking the blame for my struggles myself. I don't think you should. It takes time, and effort. There is a hump. I have dedicated a large amount of the last ten years trying to help fix that problem. It is very real.
        JohnFen 4y ago
        I very much appreciate your explanations, as well as your reassuring words. Thank you.
        steveklabnik 4y ago
        You’re welcome. Good luck :)
        4y ago
- selfmodruntime 4y ago
  To be fair, you can‘t really blame the complexity of a framework on the language. A similar comparison would be having gripes about C++ because of boost. On the other hand, I am often dissatisfied with tokio‘s incredible complexity and the fact that it‘s the accepted async solution in the ecosystem.
  - convolvatron 4y ago
    yeah. I don't think 'this sucks lets do something else' is generally well received here. plus you already have a limited selection of those crates that are async and aligned with the rest of the runtime. losing tokio would pretty much mean 80s style programming with no crates - definite no no
- cmrdporcupine 4y ago
  async & tokio can be a problem. Rust is much nicer to work with without them. My take... I can see their use, but they should be confined to the outer layers of the onion. Core components need not (should not) be written in this style. async is just a function returning a promise. Its convenience at the front end of the application shouldn't be allowed to cause distress at the lower levels.

deleted 4y ago

[deleted]

convolvatron 4y ago

I'm a low level programmer, and programming in rust feels exactly like someone is taking the control I need to do my job away from me. maybe I'm wrong, and I can get it back by reverse engineering the whole stack and getting underneath things like tokio.

JohnFen 4y ago
As a Rust newbie, here's a chance for my understanding to be corrected, but... Isn't taking control away from the programmer the entire point of Rust? I thought the premise of it is that programmers can't be trusted. That sounds like a criticism, but I don't mean it as such. It's just what I hear when I hear people talking about the value of Rust. Is my understanding incorrect?
- convolvatron 4y ago
  no. I don't think you're wrong. I was just adding a counterpoint to the above. as an old lisp programmer I really think systems should be less opaque. make things accessible and simple and useful, but make it easy to keep unwrapping. rust disturbs that journey by #deriving over the underlying truth to make things simple. but when you have to crack that open its a lot stuff to digest. I don't think rust is _wrong_, I just think that value statement you just made should be more explicit. and maybe rust devotees shouldn't be so quick to tell you that your high level goal is incorrect because its something rust doesn't handle well.
- Measter 4y ago
  I would disagree. Rust's borrow checker and other static analysis are more akin to the safety guards on a table saw. For 95% of situations they're just protect you by catching your mistakes, but there are times when the guard makes it hard or impossible to do what you need to. In those situations, if you really need to do the work, you take the guards off for that work (unsafe would be the Rust equivalent), then put them back on afterwards.
  - steveklabnik 4y ago
    You’re totally right. I often cite https://www.sawstop.com/ https://www.sawstop.com/ as an even deeper analogy, in my opinion!
  - JohnFen 4y ago
    Huh. I think perhaps I was thinking a bit wrong about "unsafe". My take on it was that it's a kind of cheating and its use would be disallowed in commercial production environments. At least, it seems to get badmouthed a lot.
    - convolvatron 4y ago
      maybe unsafe rust is pretty ok to work in. as you say, I've never been in a shop where that was allowed
    - steveklabnik 4y ago
      > its use would be disallowed in commercial production environments. Working in embedded, completely banning unsafe would be impossible. Minimizing it is a good thing, generally. But it's there to be used.
- steveklabnik 4y ago
  > Isn't taking control away from the programmer the entire point of Rust? Not in my perspective. It is about managing complexity. Rust allows you to take that "ultimate control," and then wrap it up in an easier to use package that doesn't have sharp edges. There is nothing you can't do in Rust if you want to. Heck, inline assembly is an actual part of the language, unlike in C and C++, where they're both vendor extensions!
  - JohnFen 4y ago
    > then wrap it up in an easier to use package I can't wait until I can start to see how anything about Rust is "easier to use". It's a slog for me right now, and I usually pick up new languages pretty easily. Again, not criticizing Rust. I'm taking the blame for my struggles myself.
    - steveklabnik 4y ago
      In this context, I'm not talking about usability in a general sense, I'm talking about "You don't need to consider if you're invoking UB with safe functions, unlike with unsafe functions, because the compiler checks things for you, so the number of considerations is smaller." You're right that maybe given that "easier" can mean many things to many people, I should have maybe chosen a different words. > I'm taking the blame for my struggles myself. I don't think you should. It takes time, and effort. There is a hump. I have dedicated a large amount of the last ten years trying to help fix that problem. It is very real.
      - JohnFen 4y ago
        I very much appreciate your explanations, as well as your reassuring words. Thank you.
        steveklabnik 4y ago
        You’re welcome. Good luck :)
      - 4y ago
selfmodruntime 4y ago
To be fair, you can‘t really blame the complexity of a framework on the language. A similar comparison would be having gripes about C++ because of boost. On the other hand, I am often dissatisfied with tokio‘s incredible complexity and the fact that it‘s the accepted async solution in the ecosystem.
- convolvatron 4y ago
  yeah. I don't think 'this sucks lets do something else' is generally well received here. plus you already have a limited selection of those crates that are async and aligned with the rest of the runtime. losing tokio would pretty much mean 80s style programming with no crates - definite no no
cmrdporcupine 4y ago
async & tokio can be a problem. Rust is much nicer to work with without them. My take... I can see their use, but they should be confined to the outer layers of the onion. Core components need not (should not) be written in this style. async is just a function returning a promise. Its convenience at the front end of the application shouldn't be allowed to cause distress at the lower levels.