4 ms·

> The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. TypeScript has an equally powerful type system. Pytho

> The answer for why folks are so inclined towards doing high-level tasks in Rust... is the type system. TypeScript has an equally powerful type system. Python's type system is almost as good. Both have are significantly more productive when it comes to writing software, and have bigger ecosystems and lower learning curves. > It makes a lot of progress towards the goal of "make invalid states unrepresentable", which could be really useful for web apps. TypeScript and Elm are both good at this while being useful for web development today.

fallingsquirrel 2y ago
> TypeScript has an equally powerful type system. How does TypeScript's type system prevent shared mutable state?
- throw10920 2y ago
  When did threading get added to JavaScript? And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
  - fallingsquirrel 2y ago
    > When did threading get added to JavaScript? Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) > And does Rust have type unions and intersections, interfaces, and mapped and conditional types? You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security. [1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
    - throw10920 2y ago
      > Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) ...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. > usually So, not always. That is - TypeScript's type system contains features that Rust's does not have.
      - fallingsquirrel 2y ago
        > which is an extremely rare source of bugs Confidently asserted, but very debatable. > The vast majority of errors caused by shared mutable state are related to concurrency. Concurrency, like async-await, you mean? > TypeScript's type system contains features that Rust's does not have Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).
        deleted 2y ago
        [deleted]
      - dymk 2y ago
        > which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. Simply so untrue I’m not going to elaborate further
        deleted 2y ago
        [deleted]
      - miki123211 2y ago
        JS has concurrency (but not parallelism) despite being single-threaded, though. If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes. Same applies to older mechanisms like callbacks and promises. Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.
  - dathinab 2y ago
    > When did threading get added to JavaScript? idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar. But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful. > And does Rust have type unions and intersections, interfaces, and mapped and conditional types? Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system. Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case. (and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)
- shepherdjerred 2y ago
  That is done by the compiler, not the type system
- pjmlp 2y ago
  How does Rust's type system prevent shared mutable state for out-of-process data common in distributed computing? It doesn't.
  - super_flanker 2y ago
    Just curious, which programming language allows preventing shared mutable state for out-of-process data?
    - pjmlp 2y ago
      None.
kaoD 2y ago
As someone who loves both TS and Rust: you couldn't be more wrong. TS is not even half as good at making invalid states unrepresentable. A simple example of the (many) things you can't do in TS: struct StateStart; struct StateEnd; impl StateStart { fn foo(self) -> StateEnd { StateEnd } } fn main() { let start = StateStart; let end = start.foo(); let another_end = start.foo(); // this won't compile } Try doing that without a runtime crash in TS. Super useful pattern for state machines (which are the building block of computing). I miss more features of Rust in TS that features of TS in Rust. All the time.
- WuxiFingerHold 2y ago
  Interesting, great example. This kind of compile time safety can't be achieved without borrow checker, I guess? I'm now thinking hard if there's some type magic similar to the exhaustive checks for Typescript discriminated unions ("kind satisfies never" checks in switch statements).
  - kaoD 2y ago
    I've been trying to come up with a similar pattern in TS many times but I think you cannot do this due to the lack of moves (bindings do alias, pass by reference). But TS has so many dark magical patterns that I'm still hoping to be proven wrong.

fallingsquirrel 2y ago

> TypeScript has an equally powerful type system. How does TypeScript's type system prevent shared mutable state?

throw10920 2y ago
When did threading get added to JavaScript? And does Rust have type unions and intersections, interfaces, and mapped and conditional types?
- fallingsquirrel 2y ago
  > When did threading get added to JavaScript? Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) > And does Rust have type unions and intersections, interfaces, and mapped and conditional types? You can typically accomplish the same thing with enums/proc macros/traits of course—with the additional benefit that the type system is designed to be sound. Soundness is an explicit non-goal of TypeScript[1], so once you start layering on those kinds of overly-clever types, you soon reach a point where you're just lulling yourself into a false sense of security. [1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
  - throw10920 2y ago
    > Shared mutable state is a problem even in single threaded code (for example, modifying a collection you're iterating over) ...which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. > usually So, not always. That is - TypeScript's type system contains features that Rust's does not have.
    - fallingsquirrel 2y ago
      > which is an extremely rare source of bugs Confidently asserted, but very debatable. > The vast majority of errors caused by shared mutable state are related to concurrency. Concurrency, like async-await, you mean? > TypeScript's type system contains features that Rust's does not have Sure, and likewise Rust's type system contains features TypeScript's does not have—for example, just try expressing anything close to traits with TS's type-erased generics. Since the feature sets aren't the same, I suppose it's a matter of opinion which type system is preferable. But I know which one is more helpful for me for sure (especially considering the aforementioned soundness issues).
      - deleted 2y ago
        [deleted]
    - dymk 2y ago
      > which is an extremely rare source of bugs. The vast majority of errors caused by shared mutable state are related to concurrency. Simply so untrue I’m not going to elaborate further
      - deleted 2y ago
        [deleted]
    - miki123211 2y ago
      JS has concurrency (but not parallelism) despite being single-threaded, though. If you ever put an await anywhere in your code, an arbitrary amount of random stuff might run between the time you await and the time the awaiting finishes. Same applies to older mechanisms like callbacks and promises. Race conditions are more rare there because as long as you aren't doing any IO, there is indeed no concurrency, so you can't e.g. get two threads trying to increment a single variable at the same time. They can still happen, though, especially if you accidentally do a partial change to an object, put it in an illegal state, and do IO before you finish that change.
- dathinab 2y ago
  > When did threading get added to JavaScript? idk. many years ago through stuff like service workers, having shared memory through TypedArrays and similar. But for the discussion more relevant is that shared mutability constraints do not only matter with threading, they matter with any form of concurrency (like JS async/await/promises and before that callbacks). And even without that you still have other single threaded and single tasked concurrency with the classic being changing a collection while iterating over it. So even without classical forms multi threaded concurrency still very helpful. > And does Rust have type unions and intersections, interfaces, and mapped and conditional types? Rusts type system is mainly nominal typed while TS is mainly structural types so it's a bit hard to compare. Like if you nitpick then you could maybe argue that based on TS type system having "features rust types system doesn't have" it's more powerful (but you also could argue the other way around it depends on how you count them). But that would be misleading as it ignores that not only are they two fundamentally different approaches to typing it also ignores that some features are implemented through other means outside of the type system. Practically having used both I can say that while TS has some things in the typing which are a bit cumbersome to do in rust when it comes to helping me having correct code in context of changes, especially larger changes, and especially libraries Rust still yields better results in my experience. Naturally assuming you don't abuse the TS in either case. (and to technically answer the question, type unions == yes but different, intersection == no but also make little sense in rust, interfaces == yes but different, mapped types ~= depends on the aspect in some yes and better then TS in other no but implicitly through derives so worse then TS, conditional type ~= again handled through different features depending on usage either associated types or feature gates)
shepherdjerred 2y ago
That is done by the compiler, not the type system
pjmlp 2y ago
How does Rust's type system prevent shared mutable state for out-of-process data common in distributed computing? It doesn't.
- super_flanker 2y ago
  Just curious, which programming language allows preventing shared mutable state for out-of-process data?
  - pjmlp 2y ago
    None.

kaoD 2y ago

As someone who loves both TS and Rust: you couldn't be more wrong. TS is not even half as good at making invalid states unrepresentable. A simple example of the (many) things you can't do in TS: struct StateStart; struct StateEnd; impl StateStart { fn foo(self) -> StateEnd { StateEnd } } fn main() { let start = StateStart; let end = start.foo(); let another_end = start.foo(); // this won't compile } Try doing that without a runtime crash in TS. Super useful pattern for state machines (which are the building block of computing). I miss more features of Rust in TS that features of TS in Rust. All the time.

WuxiFingerHold 2y ago
Interesting, great example. This kind of compile time safety can't be achieved without borrow checker, I guess? I'm now thinking hard if there's some type magic similar to the exhaustive checks for Typescript discriminated unions ("kind satisfies never" checks in switch statements).
- kaoD 2y ago
  I've been trying to come up with a similar pattern in TS many times but I think you cannot do this due to the lack of moves (bindings do alias, pass by reference). But TS has so many dark magical patterns that I'm still hoping to be proven wrong.