[9question1]

I love Typescript but I think I disagree with this. The point of the post seems to be that features of the Rust compiler help enforce that you use certain runtime / environment / domain semantics in ways that eliminate common classes of errors. That's never going to prevent all errors, but preventing large groups of common errors so that you only have to manually remember a smaller set of runtime/environment/domain semantics could have some value.

[0x1ceb00da]

It isn't typescript's fault. Borrow checker won't save you from bugs in your SQL queries that you send to the DBMS. Typescript doesn't care about the browser just like rust doesn't care about SQL

[bryanlarsen]

SeaORM and similar crates in Rust will catch some common SQL bugs through the type system.

[morcus]

Typescript also has ORMs.

The problem is not with TypeScript or even JavaScript but an odd Browser API where mutating some random value of an object results in a redirect on the page, but not synchronously.

Even if the language of the browser were Rust, there's nothing about the type system specifically that would have caught this bug (as far as I can tell, anyways. Presumably there's something in the background periodically reading the value of `href` and updating the page accordingly, but since that background job only would have needed read and not write access to the variable, I don't think the borrow checker would have helped here)

[e-topy]

> Setting the value of href navigates to the provided URL [0]

It would have been caught because this API (setters) is impossible with Rust. At best, you'd have a .set_href(String).await, which would stop the thread until the location has been updated and therefore the value stabilized. At worst, you'd have a public .href variable, but because the setter pattern is impossible, you know there must be some process checking and scheduling updates.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Location/hr...