5 ms·

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

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

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.