5 ms·

When the carrier trait lands this becomes: let id = node.parent()? .parent()? .data_get("id")? .parse::<

by bbatha 10y ago

When the carrier trait lands this becomes: let id = node.parent()? .parent()? .data_get("id")? .parse::<usize>() .ok()?; I'd also expect that someone will write higher level libraries so that you aren't doing raw DOM manipulation. A rust vdom wasm library would probably be blazing fast.

libria 10y ago
Swell! I was hoping that existed in this language. The rest of the code looks concise FWIW, https://github.com/tcr/rust-todomvc/blob/master/src/main.rs https://github.com/tcr/rust-todomvc/blob/master/src/main.rs
leeoniya 10y ago
> A rust vdom wasm library would probably be blazing fast. Most of the cost of vdom is the resulting DOM ops and reflow/restyle the browser needs to do. It may be faster than the fastest today, but you're unlikely to see any kind of performance leap or even anything noticeable.
steveklabnik 10y ago
Small note, we don't _technically have to stabilize Carrier to land this, just implement it for Option. (yay standard library types) However, ? for Option is a bit controversial, so we'll see...
- masklinn 10y ago
  > However, ? for Option is a bit controversial Because people wouldn't expect it to return due to behaviour of existing languages yet that's what it does in Rust?
  - Rusky 10y ago
    More because Option is not really intended to handle errors while Result and ? are.
    - steveklabnik 10y ago
      Yes, that's correct. If we make ? go to more than just result, you could implement it for any type, and it's not totally clear that changing it from "error handling" to "general control flow" is a good idea. Many are in favor of doing it, though. I'm personally against it.
      - int_19h 10y ago
        Whether it's ? or something else, having a very concise form of syntactic sugar to unwrap option types is desirable. Most languages that don't have it, eventually acquire it due to demand.
lobster_johnson 10y ago
The "?" operator looks like a more specialized, error/success-specific version of monads. Has there been any discussion about generalizing everything into monad-style chaining operators? I see that there is some discussion here [1], including a suggestion to add a Haskell-style "do" block. But that's just one guy's blog post. [1] https://m4rw3r.github.io/rust-questionmark-operator https://m4rw3r.github.io/rust-questionmark-operator.
- steveklabnik 10y ago
  Yes, that was endlessly discussed as part of all of this. The TL;DR is: it's not simple. ? is very straightforward and helps people out a lot today. So if and when (and it is a big if) Rust ever gets do notation, this might be a little redundant, but blocking one of people's largest pain points today is worth the (possible) little bit of redundancy.
  - lobster_johnson 10y ago
    Thanks, that makes perfect sense. I haven't followed the internal discussion at all. It sounds like there are some that would like to move Rust in the direction of becoming more Haskell/ML-like (which is to say more purely functional) rather than the current balance between imperative and functional? Is there any internal tension in that regard?
    - steveklabnik 10y ago
      It's not even a philosophical difference, really, there are technical objections that would have to be addressed somehow before it would even be possible, let alone figure out if it's a feature that's desired. These involve things like "it's still unclear if HKT is going to end up in Rust or not, and how", which is a pre-requirement, as just one example.
    - mathw 10y ago
      I believe one of the biggest obstacles to a general monad system in Rust is that the type system can't actually handle it at the moment - it requires higher-kinded types, which may or may not ever actually be added to the language.
killercup 10y ago
> A rust vdom wasm library would probably be blazing fast. Even regardless of performance, it would be quite nice to have! I've been meaning[1] to build a small prototype to do something clever[2] with it, but didn't have the time yet. Feel free to steal these ideas :) [1]: https://scribbles.pascalhertleif.de/impl-virtual-dom-cli-libui.html https://scribbles.pascalhertleif.de/impl-virtual-dom-cli-lib... [2]: https://scribbles.pascalhertleif.de/rich-diffs-of-rendered-html.html https://scribbles.pascalhertleif.de/rich-diffs-of-rendered-h...
topspin 10y ago
Even without the ? sugar I don't see what's so offensive about this; the least little formatting effort produces: let id = node.parent().unwrap() .parent().unwrap() .data_get("id").unwrap() .parse::<usize>().unwrap(); If there is something horrible about that I don't see it.
- 102030485868 10y ago
  It hurts to type sometimes. Typing at work isn't really an issue since I have an ergonomic keyboard, but big side projects can sometimes hurt. ? is far easier and faster to type than .unwrap(). So no, there's nothing horrible that I see, there is something horrible that I feel though.
- oblio 10y ago
  > If there is something horrible about that I don't see it. Isn't unwrap(): a) boilerplate b) repetitive?
  - steveklabnik 10y ago
    It's boilerplate in a certain sense. Those are all points where what you've written might not work. Rust makes you deal with possible problems _somehow_. Specifically, this is a replacement for null. If you legitimately don't care, then it can feel boilerplate-y, but it also lets you start by not having to care, and then searching for unwrap and replacing it with better handling. In other words, it's boilerplate here because this particular operation has many possible failure modes, and Rust is pointing those out to you. It's repetitive in this particular instance, but doesn't have to be in general.
  - stymaar 10y ago
    c) a bad practice since it will make your program crash is a node has no parent. if the node always having a parent is a invariant of your application, you should use `expect` with a clear error message when the invariant is broken. if your node can have no parents then you want to handle this case explicitly with a `if let Some(parent) = node.parent() {` pattern.

by bbatha 10y ago

libria 10y ago

Swell! I was hoping that existed in this language. The rest of the code looks concise FWIW, https://github.com/tcr/rust-todomvc/blob/master/src/main.rs https://github.com/tcr/rust-todomvc/blob/master/src/main.rs

leeoniya 10y ago

> A rust vdom wasm library would probably be blazing fast. Most of the cost of vdom is the resulting DOM ops and reflow/restyle the browser needs to do. It may be faster than the fastest today, but you're unlikely to see any kind of performance leap or even anything noticeable.

steveklabnik 10y ago

Small note, we don't _technically have to stabilize Carrier to land this, just implement it for Option. (yay standard library types) However, ? for Option is a bit controversial, so we'll see...

masklinn 10y ago
> However, ? for Option is a bit controversial Because people wouldn't expect it to return due to behaviour of existing languages yet that's what it does in Rust?
- Rusky 10y ago
  More because Option is not really intended to handle errors while Result and ? are.
  - steveklabnik 10y ago
    Yes, that's correct. If we make ? go to more than just result, you could implement it for any type, and it's not totally clear that changing it from "error handling" to "general control flow" is a good idea. Many are in favor of doing it, though. I'm personally against it.
    - int_19h 10y ago
      Whether it's ? or something else, having a very concise form of syntactic sugar to unwrap option types is desirable. Most languages that don't have it, eventually acquire it due to demand.

lobster_johnson 10y ago

The "?" operator looks like a more specialized, error/success-specific version of monads. Has there been any discussion about generalizing everything into monad-style chaining operators? I see that there is some discussion here [1], including a suggestion to add a Haskell-style "do" block. But that's just one guy's blog post. [1] https://m4rw3r.github.io/rust-questionmark-operator https://m4rw3r.github.io/rust-questionmark-operator.

steveklabnik 10y ago
Yes, that was endlessly discussed as part of all of this. The TL;DR is: it's not simple. ? is very straightforward and helps people out a lot today. So if and when (and it is a big if) Rust ever gets do notation, this might be a little redundant, but blocking one of people's largest pain points today is worth the (possible) little bit of redundancy.
- lobster_johnson 10y ago
  Thanks, that makes perfect sense. I haven't followed the internal discussion at all. It sounds like there are some that would like to move Rust in the direction of becoming more Haskell/ML-like (which is to say more purely functional) rather than the current balance between imperative and functional? Is there any internal tension in that regard?
  - steveklabnik 10y ago
    It's not even a philosophical difference, really, there are technical objections that would have to be addressed somehow before it would even be possible, let alone figure out if it's a feature that's desired. These involve things like "it's still unclear if HKT is going to end up in Rust or not, and how", which is a pre-requirement, as just one example.
  - mathw 10y ago
    I believe one of the biggest obstacles to a general monad system in Rust is that the type system can't actually handle it at the moment - it requires higher-kinded types, which may or may not ever actually be added to the language.

killercup 10y ago

> A rust vdom wasm library would probably be blazing fast. Even regardless of performance, it would be quite nice to have! I've been meaning[1] to build a small prototype to do something clever[2] with it, but didn't have the time yet. Feel free to steal these ideas :) [1]: https://scribbles.pascalhertleif.de/impl-virtual-dom-cli-libui.html https://scribbles.pascalhertleif.de/impl-virtual-dom-cli-lib... [2]: https://scribbles.pascalhertleif.de/rich-diffs-of-rendered-html.html https://scribbles.pascalhertleif.de/rich-diffs-of-rendered-h...

topspin 10y ago

Even without the ? sugar I don't see what's so offensive about this; the least little formatting effort produces: let id = node.parent().unwrap() .parent().unwrap() .data_get("id").unwrap() .parse::<usize>().unwrap(); If there is something horrible about that I don't see it.

102030485868 10y ago
It hurts to type sometimes. Typing at work isn't really an issue since I have an ergonomic keyboard, but big side projects can sometimes hurt. ? is far easier and faster to type than .unwrap(). So no, there's nothing horrible that I see, there is something horrible that I feel though.
oblio 10y ago
> If there is something horrible about that I don't see it. Isn't unwrap(): a) boilerplate b) repetitive?
- steveklabnik 10y ago
  It's boilerplate in a certain sense. Those are all points where what you've written might not work. Rust makes you deal with possible problems _somehow_. Specifically, this is a replacement for null. If you legitimately don't care, then it can feel boilerplate-y, but it also lets you start by not having to care, and then searching for unwrap and replacing it with better handling. In other words, it's boilerplate here because this particular operation has many possible failure modes, and Rust is pointing those out to you. It's repetitive in this particular instance, but doesn't have to be in general.
- stymaar 10y ago
  c) a bad practice since it will make your program crash is a node has no parent. if the node always having a parent is a invariant of your application, you should use `expect` with a clear error message when the invariant is broken. if your node can have no parents then you want to handle this case explicitly with a `if let Some(parent) = node.parent() {` pattern.