4 ms·

These issues don't exist in languages that aren't built on a marsh. More specifically though, I feel like the way javascript libraries with types work is often

by foota 2y ago

These issues don't exist in languages that aren't built on a marsh. More specifically though, I feel like the way javascript libraries with types work is often painful to use and that's why people use TS's escape hatches, whereas the same thing doesn't happen in languages where everything is built on types from the get go. The same friction is true for example of using C libraries from other languages.

rty32 2y ago
"don't exist in languages that aren't built on a marsh" Sure. Last time I checked, JavaScript is the language that actually powers the web. If you can get a language that isn't built on a marsh along with all the libraries to run the web, I'll switch in a second. In other words, the criticism is simply irrelevant. If it works, it works. We don't talk about technologies that don't exist.
- skitter 2y ago
  We do in fact talk about technologies that don't exist. Creating new technologies would be rather difficult otherwise.
- foota 2y ago
  When they don't have to interface with JS apis (e.g., for the DOM) this is true for libraries in other languages built for WASM.
  - lolinder 2y ago
    Not run on the web, "to run the web". Maybe someday WASM will be complete enough to actually run the web, but JavaScript is what we have right now and it's done a pretty okay job so far.
golergka 2y ago
> These issues don't exist in languages that aren't built on a marsh. Unsafe casts exist in almost any GCed strongly typed language. You can unsafe things even in Rust, if you want to. Author of this code has deliberately made a choice to circumvent language's limitation and forgo it's guarantees. We have been doing it since undefined behaviour in C, how is that Typescript's fault?
- LudwigNagasena 2y ago
  > Unsafe casts exist in almost any GCed strongly typed language. Well, and not GCed languages too. There are even weakly typed associative arrays. std::map<std::string, std::any>
Too 2y ago
The rest of the world is an equally muddy marsh. C++: static_cast, C: void-pointers and unions, java/c#: casting back from (object) or IAbstractWidget. If anything, typescript has the most expressive, accurate and powerful type system of the lot, letting you be a lot more precise in your generics and then get the exact type back in your callback, rather than some abstract IWidget that needs to be cast back to the more concrete class. The structural typing also makes it much easier to be lax and let the type engine deduce correctness, rather than manually casting things around.
- leononame 2y ago
  C is famously unsafe. But in Java/C#, you do have runtime type safety. You can't just cast something to something else and call it a day. In the worst case, you'll get an exception telling you that this does not work. In TypeScript, the "cast" succeeds, but then 200 lines later, you get some weird runtime error like "does not exist on type undefined" which doesn't tell you at all what the source of the error is. In TypeScript, a variable can have a different runtime type from its declared type entirely, that's just not true for many other languages
  - trashburger 2y ago
    I'm not sure about the CLR, but the JVM has no type safety whatsoever. Java the language does, but all of that goes away once you are in the JVM bytecode.
    - drewhk 2y ago
      > the JVM has no type safety whatsoever. This is just partially true (or completely untrue in the mathematical sense since your statement is "_no_ type safety _whatsoever_" :P ). The whole purpose of the bytecode verifier is to ensure that the bytecode accesses objects according to their known type and this is enforced at classloading time. I think you meant type erasure which is related - generic types do not exist on the bytecode level, their type parameters are treated as Object. This does not violate the bytecode verifier's static guarantees of memory safety (since those Objects will be cast and the cast will be verified at runtime), but indeed, it is not a 100% mapping of the Java types - nevertheless, it is still a mapping and it is typed, just on a reduced subset.

by foota 2y ago

rty32 2y ago

"don't exist in languages that aren't built on a marsh" Sure. Last time I checked, JavaScript is the language that actually powers the web. If you can get a language that isn't built on a marsh along with all the libraries to run the web, I'll switch in a second. In other words, the criticism is simply irrelevant. If it works, it works. We don't talk about technologies that don't exist.

skitter 2y ago
We do in fact talk about technologies that don't exist. Creating new technologies would be rather difficult otherwise.
foota 2y ago
When they don't have to interface with JS apis (e.g., for the DOM) this is true for libraries in other languages built for WASM.
- lolinder 2y ago
  Not run on the web, "to run the web". Maybe someday WASM will be complete enough to actually run the web, but JavaScript is what we have right now and it's done a pretty okay job so far.

golergka 2y ago

> These issues don't exist in languages that aren't built on a marsh. Unsafe casts exist in almost any GCed strongly typed language. You can unsafe things even in Rust, if you want to. Author of this code has deliberately made a choice to circumvent language's limitation and forgo it's guarantees. We have been doing it since undefined behaviour in C, how is that Typescript's fault?

LudwigNagasena 2y ago
> Unsafe casts exist in almost any GCed strongly typed language. Well, and not GCed languages too. There are even weakly typed associative arrays. std::map<std::string, std::any>

Too 2y ago

The rest of the world is an equally muddy marsh. C++: static_cast, C: void-pointers and unions, java/c#: casting back from (object) or IAbstractWidget. If anything, typescript has the most expressive, accurate and powerful type system of the lot, letting you be a lot more precise in your generics and then get the exact type back in your callback, rather than some abstract IWidget that needs to be cast back to the more concrete class. The structural typing also makes it much easier to be lax and let the type engine deduce correctness, rather than manually casting things around.

leononame 2y ago
C is famously unsafe. But in Java/C#, you do have runtime type safety. You can't just cast something to something else and call it a day. In the worst case, you'll get an exception telling you that this does not work. In TypeScript, the "cast" succeeds, but then 200 lines later, you get some weird runtime error like "does not exist on type undefined" which doesn't tell you at all what the source of the error is. In TypeScript, a variable can have a different runtime type from its declared type entirely, that's just not true for many other languages
- trashburger 2y ago
  I'm not sure about the CLR, but the JVM has no type safety whatsoever. Java the language does, but all of that goes away once you are in the JVM bytecode.
  - drewhk 2y ago
    > the JVM has no type safety whatsoever. This is just partially true (or completely untrue in the mathematical sense since your statement is "_no_ type safety _whatsoever_" :P ). The whole purpose of the bytecode verifier is to ensure that the bytecode accesses objects according to their known type and this is enforced at classloading time. I think you meant type erasure which is related - generic types do not exist on the bytecode level, their type parameters are treated as Object. This does not violate the bytecode verifier's static guarantees of memory safety (since those Objects will be cast and the cast will be verified at runtime), but indeed, it is not a 100% mapping of the Java types - nevertheless, it is still a mapping and it is typed, just on a reduced subset.