61–70 of 80 posts
This would be even nicer if TypeScript added type inference for tagged template literals, like in this issue [1]. Then you could write: const schema = proto` syntax = "proto3"; message Person { ... } `; type Person = typeof schema['Person']; And you could get built-in schema validation with a sophisticated enough type definition for `proto`, nice syntax highlighting in many tools with a nested grammar. We would love…
Earlier quoted context omitted.
I was hoping to hear how are php types better than TS instead of another rant about how Rust is the greatest. Anyone? By the way, having lived in Scala 2 for a few years, Rust is half-assed. Type system leaks through the fingers when working with async collections. Future.sequence from Scala makes great cli apps. Scala collections are a work horse. The only thing from Rust I like is the shorthand question mark return…
lol. i mentioned rust as being the worst typed solution, to highlight ts is even beneath that.
The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…
A fun read / Video...
Earlier quoted context omitted.
I know, but it's that last bit: it shouldn't be possible to bypass it. C# actually got itself into a similar issue despite being a proper static language, because when it added "nullable reference types" (where you can't assign null to a variable of type `Foo` unless it's explicitly typed as `Foo?`) they did it like TypeScript using purely static analysis to avoid having to change the language at a lower level (for c…
On the other hand, disallowing bypassing it limits what you can do. There's always a ceiling to what the compiler can figure out, and some very complex types can't be analysed statically right now. By allowing bypassing the system, I can still accurately type those functions and reap all the rewards, and I can make sure everything works by combining unit tests with type unit tests. If bypassing was disallowed, I'd be…
Even inside the Typescript rules, `as` is a ridiculously dangerous timebomb.
Typescript is 100% about "convenience" and write-lots-of-code-now style of productivity, ~0% about safety or long-term maintainability.
This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…
Might as well do code generation at that point, it'd even be debuggable.
Earlier quoted context omitted.
On the other hand, disallowing bypassing it limits what you can do. There's always a ceiling to what the compiler can figure out, and some very complex types can't be analysed statically right now. By allowing bypassing the system, I can still accurately type those functions and reap all the rewards, and I can make sure everything works by combining unit tests with type unit tests. If bypassing was disallowed, I'd be…
Safety bypasses should be opt-in, case by case, and very explicit. For example, Rust's `unsafe` allows bypassing any limitation the language safety imposes on you normally, but all code not explicitly labeled unsafe is always in the very very safe mode. Even inside the Typescript rules, `as` is a ridiculously dangerous timebomb. Typescript is 100% about "convenience" and write-lots-of-code-now style of productivity,…
Earlier quoted context omitted.
Safety bypasses should be opt-in, case by case, and very explicit. For example, Rust's `unsafe` allows bypassing any limitation the language safety imposes on you normally, but all code not explicitly labeled unsafe is always in the very very safe mode. Even inside the Typescript rules, `as` is a ridiculously dangerous timebomb. Typescript is 100% about "convenience" and write-lots-of-code-now style of productivity,…
What's the big difference between `unsafe` and `as` regarding explicit labelling? Both are opt-in and explicit. As the user of a function, you don't see either from the outside. If you don't like `as`, it's fine to use a linter to disallow it.
Grepping a real world codebase that would not be `unsafe` in Rust:
event as CustomEvent
const errorEvent = event as ErrorEvent;
const element = getByRole("textbox");
expect(element).toBeInstanceOf(HTMLInputElement);
const input = element as HTMLInputElement;
const element = parent.firstElementChild as HTMLElement;
type ItemMap = Map;
...
new Map() as ItemMap
const clusterSource = this.map.getSource(sourceName) as GeoJSONSource;
[K in keyof T as T[K] extends Fn ? K : never]: T[K];
target[type] as unknown as FnEarlier quoted context omitted.
You’re talking about runtime, I’m talking about at compile time
No, I'm talking about compile time. A loader at compile time (e.g., for webpack) takes whatever your import path is and translates it into something that can be used by the JavaScript application. It would be awfully silly to do this at runtime because typescript doesn't exist at runtime, which is sort of the whole point of the library.
Earlier quoted context omitted.
What's the big difference between `unsafe` and `as` regarding explicit labelling? Both are opt-in and explicit. As the user of a function, you don't see either from the outside. If you don't like `as`, it's fine to use a linter to disallow it.
The difference is that in everyday Typescript you end up using `as`, so it's presence is not a blaring alarm. Grepping a real world codebase that would not be `unsafe` in Rust: event as CustomEvent const errorEvent = event as ErrorEvent; const element = getByRole("textbox"); expect(element).toBeInstanceOf(HTMLInputElement); const input = element as HTMLInputElement; const element = parent.firstElementChild as HTMLEle…
It's on you to ensure that you don't misuse `as`. If I could choose between current TS, and a "safer" one that's less expressive in complex cases, I'd choose the current one any day of the week.
Earlier quoted context omitted.
The difference is that in everyday Typescript you end up using `as`, so it's presence is not a blaring alarm. Grepping a real world codebase that would not be `unsafe` in Rust: event as CustomEvent const errorEvent = event as ErrorEvent; const element = getByRole("textbox"); expect(element).toBeInstanceOf(HTMLInputElement); const input = element as HTMLInputElement; const element = parent.firstElementChild as HTMLEle…
Many, if not most, of these occurrences can be made safe. It's very rare that I need `as`, and even more rare that I can't actually check the relevant properties at runtime to ensure the code path is valid. It's on you to ensure that you don't misuse `as`. If I could choose between current TS, and a "safer" one that's less expressive in complex cases, I'd choose the current one any day of the week.