Re:Rewriting TypeScript in Rust? You'D have to be
by htkibar on Wednesday December 14, 2022 @12:51PM
(#33987037)
Allows competing implementations and saves TS from MSFT
Re:Rewriting TypeScript in Rust? You'D have to be
by rk06 on Wednesday December 14, 2022 @01:58PM
(#33988257)
Right now:
1.It's not doing what I expect.
2.Is it intentional behavior or a bug?
3. Let's ask on github/reddit etc
With Special:
1. It is not doing what I expect
2. Is this a spec issue or code issue?
3. Let's check spec.
4a. "Working as specified". Shit. Hope spec improves in future versions
4b. It is not working as spec says. Let's file a bug on tsc.
And that is the difference.
Re:Rewriting TypeScript in Rust? You'D have to be
by steveklabnik on Wednesday December 14, 2022 @04:40PM
(#33990993)
The real rub is in step 4: it is not always easy to determine what the spec means. And then you're basically back to "let's ask on github/reddit etc."
Re:Rewriting TypeScript in Rust? You'D have to be
by yencabulator on Wednesday December 14, 2022 @05:06PM
(#33991286)
Just because the comprehensiveness of something is on a spectrum is not a reason to just not bother and have none at all.
Also, when done well a spec is a great way to learn & understand the language too. http://golang.org/ref/spec is so much more usable than Typescript's docs.
Re:Rewriting TypeScript in Rust? You'D have to be
by steveklabnik on Wednesday December 14, 2022 @05:36PM
(#33991693)
I agree that specifications are useful. I also think they're often presented as a panacea. It is important to acknowledge that they're a tool, with pros and cons, like any tool. The existence of a specification does not immediately mean that any and all ambiguities are resolved.
Re:Rewriting TypeScript in Rust? You'D have to be
by tshaddox on Wednesday December 14, 2022 @06:45PM
(#33992619)
Still doesn’t seem like much a difference. If you run into 4a you still file an issue somewhere.
Re:Rewriting TypeScript in Rust? You'D have to be
by randomdata on Thursday December 15, 2022 @03:46AM
(#33996847)
If an implementation isn't doing what you expect, is it just an issue with that single implementation? A problem with all implementations? A problem with what you expect? If another implementation does do what you expect is it correct or just lucky?
A spec resolves such discrepancies. Indeed, the spec may be where the problem is, but once the spec is corrected then implementations know what they must do. Absent of a spec, who knows?
It's not doing what I expect. Oh? Change the code
How is that different from now?