Hacker News Reader

Comment by bbatha | Hacker News Reader

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.

View on HN

> 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-lib... [2]: https://scribbles.pascalhertleif.de/rich-diffs-of-rendered-h...

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.

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.

> If there is something horrible about that I don't see it.

Isn't unwrap():

a) boilerplate

b) repetitive?

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.

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.

Some people prefer their languages to be more concise, and the safety of the the option objects (and the requirement of the unwrap() calls in the function chain) feels unwieldy. Moreover, as the unwrap() calls could panic if there's no attribute, the more complete handling of it is even longer (match calls and following the successful path).

This could be a function to isolate just the attribute you need, but seeing the example as it is presented can be off-putting from people used to scripting languages like ruby/python, which are more concise.

Unwrap will panic if no parent is found, whereas the `?` operator allows for a clean handling of this situation.

Dealing with this case properly without using a single `?`, gets really ugly with a lot of nested

    if let Some(parent) = node.parent() {

> 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.

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.

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.

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?

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.

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.

There's another problem too: a monad trait would unify types behind a monadic interface, but many things that in Haskell are types, are traits in Rust. This is because Rust requires a single type to have uniform memory representation and to be statically dispatchable (save for trait objects). So in Rust, there is not just an "iterator type", but multiple types that have the Iterator trait. The same goes for Future trait.

This leads to a situation where, if there were to be a monad trait, that trait should abstract over not only types, but another traits generically.

Not to speak about some other hurdles, like lifetimes. The design space is inherently more convoluted than in languages with boxed, possibly dynamically dispatched types. It may be possible, but it's not easy, and we can't copy the monads straightforwardly from Haskell or Scala.

Good point! A whole other set of things also need to be hoisted to make this work.

The semantics of ? are different from monadic bind and fit better to Rust's language context of strictness, imperativeness, and mutability than Monad (which is a problematic type class in Rust for some separate reasons).

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

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...

> 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?

More because Option is not really intended to handle errors while Result and ? are.

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.

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.

Reply on news.ycombinator.com