5 ms·

Typescript was my stepping stone into the world of Rust. Even before Deno made it easy, it was straightforward enough to configure a simple tsconfig and just r

Typescript was my stepping stone into the world of Rust. Even before Deno made it easy, it was straightforward enough to configure a simple tsconfig and just run tsc. Much like cargo, there is a lot to be said for "it just works" tooling - especially for beginners or even new programmers. It is probably fair to say it is one of the most influential and impactful languages of all time. There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

krapp 4y ago
> There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations ... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.
- kuramitropolis 4y ago
  ...as optional hints that don't require you to buy into a whole new toolchain.
  - krapp 4y ago
    I would prefer if they actually had a purpose in the language in which they were used (JS.) Add optional type hinting to JS itself, if it's that important, don't add pretend type hinting to it because typescript users don't want to have to use their compilers anymore. I know a lot of people like it but it just seems like an ugly hack to me, extra syntax for the sake of an abritrary third party tool. I know I'm a dinosaur. I want to go back to the days of JQuery modules and FTP. Feh.
- olitech 4y ago
  I'd disagree that its a poor decision, some help is better than no help when reading code - and if it's inline then it's intrinsically meaningful. By no means is it perfect, the language doesn't enforce the type rules, but that the developer has the option is far better than not. As far as I can tell the proposal would pretty similar to Python; one can misleadingly or accidentally misuse type hints like the following: def myfn(a: int) -> str: return int(a) print(myfn("42")) But when done right, it gives you a leg up when you come back to read your own code or scan over someone else's. When you're reading over other's code in group programming assignments, comments make a world of difference (a niche example). It is a choice, but its use in code might just inspire someone to investigate further - my own introduction to types in programming came when I wondered what these oddly placed colons and arrows were in some Python I came across. If they do add these annotations to JavaScript, some future programmer browsing the source of a web page may well just stumble upon types and have a whole new world of theory opened up to them - I'm all for it.
  - schwartzworld 4y ago
    That's fine for atomic types like string or int, but typescript goes a lot deeper than that with powerful generics. For example, I'm working on a library of functional data wrappers. This would be useless without Typescript and impossible to type without generics. There's also no way to share and reuse types in comments. Do you copy paste comments to "type" things? What about complex objects? What happens if the comments get out of sync? How do you test them? I used to be a typescript skeptic too, but much of that skepticism tends to come from drastically underestimating the power of the TS type system.
- seeekr 4y ago
  I just want to note that it seems incorrect to call this a superficial resemblance in terms of syntax. I went and read through the whole thing, and the syntax for the type hints seems to be as close to 100% TypeScript as possible, which is to say, it is very close. There may be some features missing that TS supports, but the bulk of it is there, and what's there is basically Typescript, which is the best thing that could possibly be accomplished here. Typescript has been doing a fantastic job, and this proposal is continuing in that same vein, truly absorbing as much of that as possible back into JS! Kudos to everyone involved, great effort! And re "[the type hints] do nothing": The section at the end of the proposal clearly explains why that must necessarily be the case: Evolutions of JS must not break the web (especially) for the users. Quoting: "TypeScript's model -- which has been highly successful for JS developers -- is around non-local, best-effort checks. (...) Additionally, defining a type system to run directly in the browser means that improved type analyses would become breaking changes for the users of JavaScript applications, rather than for developers. This would violate goals around web compatibility (i.e. "don't break the web"), so type system innovation would become near-impossible. Allowing other type systems to analyze code separately provides developers with choice, innovation, and freedom for developers to opt-out of checking at any time." So this proposal provides the best possible path forward for JS, based on what folks are voting for with their feet by using TS: Making JS compatible with TS-style type hints that can be used by external tools (i.e. not the JS engines executing the code at runtime) to validate the code in a best-effort manner while the developer is looking at it, while not changing JS runtime semantics and thus never breaking the code while the user is running it.
- jmull 4y ago
  I don't see the problem with this design decision. I'm not the biggest fan of static type checking (especially in a language like Javascript, where it isn't used for safety guarantees), but it has its uses. The "as comments" part of it isn't about syntax. They really mean no runtime overhead/behavior. (I don't think they should have put it that way -- it's just going to cause confusion.) Is there really any question that "no runtime overhead" needs to be an option? (I think any proposal that didn't include this would be DOA.) It also seems clear to me it needs to be the default option, for multiple reasons (language changes should be backwards compatible as much as possible, it should be easy to adopt new language features incrementally, type usage is an application-level concern. Note: there's nothing in this proposal that prevents run-time enforcement. Good design limits scope but keeps your options open.
kuramitropolis 4y ago
Opposite experience. Rust was my stepping stone into "hey, maybe JS will be better with some degree of static typing?" Yes it would. But not the way TypeScript does it though, and there aren't any other viable options, are there? TypeScript brands itself a "superset" of JavaScript. In practice, it arbitrarily invalidates completely sensible JavaScript idioms.
- wiseowise 4y ago
  > In practice, it arbitrarily invalidates completely sensible JavaScript idioms. Such as?
  - deleted 4y ago
    [deleted]
  - kuramitropolis 4y ago
    For one, try redefining a property as a getter/setter pair in a subclass. Also, try implementing a function that takes keyword arguments, some of which are required, and some of which have default values. I'll wait. When you're back I might've remembered some more.
    - purplerabbit 4y ago
      You’re right on the first (although classes are out of fashion, so this is low impact) On the second, doesn’t this work?: ‘function foo({ bar = 3 }: { bar?: number })’
      - kuramitropolis 4y ago
        >You’re right on the first Strictly speaking, it takes exactly one such behavior (that you cannot even disable) for TS to stop being a superset of JS. >although classes are out of fashion, so this is low impact Looking at the TSC codebase, so are keyword arguments. The "in" thing is just to write very very long lines of multiple verbosely named positional arguments instead. That said, "clases are out of fashion" is a complete non-argument. I'm of the functional persuasion, yet I've found that classes are the ony way to write TypeScript that fits on your screen at all. Especially now that classes are being introduced in JavaScript proper, and of course TypeScript does them only slightly differently (handling of default property values and "definedness" differs). >On the second, doesn’t this work?: ‘function foo({ bar = 3 }: { bar?: number })’ You also need a `= {}` there, otherwise you'll need to call `foo({})` - it won't let you call `foo()`. This is also in JS though, so a bad example of TS breaking things (`function foo ({ bar })` still won't work though). There are probably better ones that people encounter, work around, and forget about, because nobody's listening anyway. "The code making sense is not important, what's important is helping the user" lol. Now imagine how the above looks with 5-10 kwargs (because keeping context in the class instance is "out of fashion", so it's either a ton of args per function or a "context" record which is effectively reimplementing classes but with a worse experience), and an aggressive formatter insisting every individual thing has to be in its own line. Here's another: failing to infer the type of `this.constructor`. Sure, the constructor signature may change in a subclass (why not disallow incompatible constructor overrides, given incompatible property/method signatures are already disallowed?); then what about static methods accessed via `this.constructor`? So you end up defining an interface type for the constructor and using `(this.constructor as MyConstructorType).staticMethod` or whatever. Which is just visual noise where the fucking intent of the code was previously clear as day, so clear that TSC should've been able to infer it (yeah the type inference also sucks). Also, ever seen TS2322? It's my pet now. What it do All in all, TS really puts the "Java" back in JavaScript, and then some. EDIT: Also crap like not being able to have a question mark and a default value in positional arguments so you gotta add `|undefined` there. Even the stuff it adds on top of JS is poorly thought out.
an1sotropy 4y ago
Is there any news about the status of the type-annotations-as-comments proposal? The README has said "Details will change in the coming days" since March 31. I know TCs are supposed to move deliberately, but this is such a neat idea I'm impatient.

krapp 4y ago

> There's even the future possibility of much of its type syntax being absorbed back into JavaScript: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations ... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.

kuramitropolis 4y ago
...as optional hints that don't require you to buy into a whole new toolchain.
- krapp 4y ago
  I would prefer if they actually had a purpose in the language in which they were used (JS.) Add optional type hinting to JS itself, if it's that important, don't add pretend type hinting to it because typescript users don't want to have to use their compilers anymore. I know a lot of people like it but it just seems like an ugly hack to me, extra syntax for the sake of an abritrary third party tool. I know I'm a dinosaur. I want to go back to the days of JQuery modules and FTP. Feh.
olitech 4y ago
I'd disagree that its a poor decision, some help is better than no help when reading code - and if it's inline then it's intrinsically meaningful. By no means is it perfect, the language doesn't enforce the type rules, but that the developer has the option is far better than not. As far as I can tell the proposal would pretty similar to Python; one can misleadingly or accidentally misuse type hints like the following: def myfn(a: int) -> str: return int(a) print(myfn("42")) But when done right, it gives you a leg up when you come back to read your own code or scan over someone else's. When you're reading over other's code in group programming assignments, comments make a world of difference (a niche example). It is a choice, but its use in code might just inspire someone to investigate further - my own introduction to types in programming came when I wondered what these oddly placed colons and arrows were in some Python I came across. If they do add these annotations to JavaScript, some future programmer browsing the source of a web page may well just stumble upon types and have a whole new world of theory opened up to them - I'm all for it.
- schwartzworld 4y ago
  That's fine for atomic types like string or int, but typescript goes a lot deeper than that with powerful generics. For example, I'm working on a library of functional data wrappers. This would be useless without Typescript and impossible to type without generics. There's also no way to share and reuse types in comments. Do you copy paste comments to "type" things? What about complex objects? What happens if the comments get out of sync? How do you test them? I used to be a typescript skeptic too, but much of that skepticism tends to come from drastically underestimating the power of the TS type system.
seeekr 4y ago
I just want to note that it seems incorrect to call this a superficial resemblance in terms of syntax. I went and read through the whole thing, and the syntax for the type hints seems to be as close to 100% TypeScript as possible, which is to say, it is very close. There may be some features missing that TS supports, but the bulk of it is there, and what's there is basically Typescript, which is the best thing that could possibly be accomplished here. Typescript has been doing a fantastic job, and this proposal is continuing in that same vein, truly absorbing as much of that as possible back into JS! Kudos to everyone involved, great effort! And re "[the type hints] do nothing": The section at the end of the proposal clearly explains why that must necessarily be the case: Evolutions of JS must not break the web (especially) for the users. Quoting: "TypeScript's model -- which has been highly successful for JS developers -- is around non-local, best-effort checks. (...) Additionally, defining a type system to run directly in the browser means that improved type analyses would become breaking changes for the users of JavaScript applications, rather than for developers. This would violate goals around web compatibility (i.e. "don't break the web"), so type system innovation would become near-impossible. Allowing other type systems to analyze code separately provides developers with choice, innovation, and freedom for developers to opt-out of checking at any time." So this proposal provides the best possible path forward for JS, based on what folks are voting for with their feet by using TS: Making JS compatible with TS-style type hints that can be used by external tools (i.e. not the JS engines executing the code at runtime) to validate the code in a best-effort manner while the developer is looking at it, while not changing JS runtime semantics and thus never breaking the code while the user is running it.
jmull 4y ago
I don't see the problem with this design decision. I'm not the biggest fan of static type checking (especially in a language like Javascript, where it isn't used for safety guarantees), but it has its uses. The "as comments" part of it isn't about syntax. They really mean no runtime overhead/behavior. (I don't think they should have put it that way -- it's just going to cause confusion.) Is there really any question that "no runtime overhead" needs to be an option? (I think any proposal that didn't include this would be DOA.) It also seems clear to me it needs to be the default option, for multiple reasons (language changes should be backwards compatible as much as possible, it should be easy to adopt new language features incrementally, type usage is an application-level concern. Note: there's nothing in this proposal that prevents run-time enforcement. Good design limits scope but keeps your options open.

kuramitropolis 4y ago

Opposite experience. Rust was my stepping stone into "hey, maybe JS will be better with some degree of static typing?" Yes it would. But not the way TypeScript does it though, and there aren't any other viable options, are there? TypeScript brands itself a "superset" of JavaScript. In practice, it arbitrarily invalidates completely sensible JavaScript idioms.

wiseowise 4y ago
> In practice, it arbitrarily invalidates completely sensible JavaScript idioms. Such as?
- deleted 4y ago
  [deleted]
- kuramitropolis 4y ago
  For one, try redefining a property as a getter/setter pair in a subclass. Also, try implementing a function that takes keyword arguments, some of which are required, and some of which have default values. I'll wait. When you're back I might've remembered some more.
  - purplerabbit 4y ago
    You’re right on the first (although classes are out of fashion, so this is low impact) On the second, doesn’t this work?: ‘function foo({ bar = 3 }: { bar?: number })’
    - kuramitropolis 4y ago
      >You’re right on the first Strictly speaking, it takes exactly one such behavior (that you cannot even disable) for TS to stop being a superset of JS. >although classes are out of fashion, so this is low impact Looking at the TSC codebase, so are keyword arguments. The "in" thing is just to write very very long lines of multiple verbosely named positional arguments instead. That said, "clases are out of fashion" is a complete non-argument. I'm of the functional persuasion, yet I've found that classes are the ony way to write TypeScript that fits on your screen at all. Especially now that classes are being introduced in JavaScript proper, and of course TypeScript does them only slightly differently (handling of default property values and "definedness" differs). >On the second, doesn’t this work?: ‘function foo({ bar = 3 }: { bar?: number })’ You also need a `= {}` there, otherwise you'll need to call `foo({})` - it won't let you call `foo()`. This is also in JS though, so a bad example of TS breaking things (`function foo ({ bar })` still won't work though). There are probably better ones that people encounter, work around, and forget about, because nobody's listening anyway. "The code making sense is not important, what's important is helping the user" lol. Now imagine how the above looks with 5-10 kwargs (because keeping context in the class instance is "out of fashion", so it's either a ton of args per function or a "context" record which is effectively reimplementing classes but with a worse experience), and an aggressive formatter insisting every individual thing has to be in its own line. Here's another: failing to infer the type of `this.constructor`. Sure, the constructor signature may change in a subclass (why not disallow incompatible constructor overrides, given incompatible property/method signatures are already disallowed?); then what about static methods accessed via `this.constructor`? So you end up defining an interface type for the constructor and using `(this.constructor as MyConstructorType).staticMethod` or whatever. Which is just visual noise where the fucking intent of the code was previously clear as day, so clear that TSC should've been able to infer it (yeah the type inference also sucks). Also, ever seen TS2322? It's my pet now. What it do All in all, TS really puts the "Java" back in JavaScript, and then some. EDIT: Also crap like not being able to have a question mark and a default value in positional arguments so you gotta add `|undefined` there. Even the stuff it adds on top of JS is poorly thought out.

an1sotropy 4y ago

Is there any news about the status of the type-annotations-as-comments proposal? The README has said "Details will change in the coming days" since March 31. I know TCs are supposed to move deliberately, but this is such a neat idea I'm impatient.