←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 4 comments | 27 Aug 25 15:48 UTC | HN request time: 0.001s | source
Show context
johnfn ◴[28 Aug 25 06:21 UTC] No.45049034[source]▶
I think Rust is awesome and I agree with that part of the article.

What I disagree with is that it's the fault of Typescript that the href assignment bug is not caught. I don't think that has anything to do with Typescript. The bug is that it's counter-intuitive that setting href defers the location switch until later. You could imagine the same bug in Rust if Rust had a `set_href` function that also deferred the work:

    set_href('/foo');

    if (some_condition) {
        set_href('/bar');
    }
Of course, Rust would never do this, because this is poor library design: it doesn't make sense to take action in a setter, and it doesn't make sense that assigning to href doesn't immediately navigate you to the next page. Of course, Rust would never have such a dumb library design. Perhaps I'm splitting hairs, but that's not Rust vs TypeScript - it's Rust's standard library vs the Web Platform API. To which I would totally agree that Rust would never do something so silly.
replies(7): >>45049104 #>>45049184 #>>45049492 #>>45049625 #>>45049709 #>>45052032 #>>45052981 #
1. flohofwoe ◴[28 Aug 25 06:32 UTC] No.45049104[source]▶
Objection your honor ;)

A 'setter' should never ever cause an action to be triggered, and especially not immediately inside the setter.

At the least change the naming, like `navigate_to(href)`.

But in the browser environment it's also perfectly clear why it is not happening immediately, your entire JS code is essentially just a callback which serves the browser event loop and tells it what to do next. A function which never returns to the caller doesn't fit into the overall picture.

replies(1): >>45049332 #
2. johnfn ◴[28 Aug 25 07:10 UTC] No.45049332[source]▶
That’s a good point. I actually modified my comment because I assumed everyone would take for granted that no work should be done in a setter :)

> A function which never returns to the caller doesn't fit into the overall picture.

Hmm, not sure about this. On the node side, you can process.exit() out of a callback. If setting href worked like that, I think it would be less confusing.

replies(1): >>45050371 #
3. mcherm ◴[28 Aug 25 10:07 UTC] No.45050371[source]▶
> If setting href worked like that, I think it would be less confusing.

How do you imagine this would interact with try-finally being used to clean up resources, release locks, close files, and so forth?

replies(1): >>45051543 #
4. fleabitdev ◴[28 Aug 25 12:49 UTC] No.45051543{3}[source]▶
try-finally is leaky in JavaScript, in any case. If your `try` block contains an `await` point, its finaliser may never run. The browser also has the right to stop running your tab’s process partway through a JavaScript callback without running any finalisers (for example, because the computer running the browser has been struck by lightning).

For this reason, try-finally is at best a tool for enforcing local invariants in your code. When a function like process.exit() completely retires the current JavaScript environment, there’s no harm in skipping `finally` blocks.