6 ms·

I'm interested to hear folks prediction on the future of the language. As a greyhair I've seen many languages come and go. I don't want to sound pessimistic bu

by xfitm3 5y ago

I'm interested to hear folks prediction on the future of the language. As a greyhair I've seen many languages come and go. I don't want to sound pessimistic but the idea of trading one set of problems for another isn't novel. I am of the opinion that all roads ultimately lead back to the fundamentals.

Zababa 5y ago
I think Typescript is here to stay, way more than Coffeescript was. On the other hand, I wonder if there's not a missed opportunity by compiling TS to JS. You lose all the type information that could be used to optimize the code.
- arcanon 5y ago
  How so? Coffeescript was mostly absorbed by JS, a true success story. The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. OP might be on to something, not wanting to waste time chasing trend n-1
  - mcphage 5y ago
    > The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. What do you see them moving to?
    - arcanon 5y ago
      Linky: https://www.google.com/amp/s/startfunction.com/deno-will-stop-using-typescript/%3famp https://www.google.com/amp/s/startfunction.com/deno-will-sto...
      - Zababa 5y ago
        This is just a Deno-specific internal thing due to tsc being too slow for their specific case. Deno itself can read and execute TS code and they aren't planning on dropping that.
        arcanon 5y ago
        Right, they just wouldn’t use it themselves.
        Zababa 5y ago
        In the original design doc: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... > Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
  - Zababa 5y ago
    Intertia. TS is way more popular than Coffeescript ever was, so there will be more code to maintain, and the network effect applies here. > The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. Who are these people, why are they moving away from it? > OP might be on to something, not wanting to waste time chasing trend n-1 If you need static typing for JS now, TS is your best bet. You can also wait N years for TC-39 to add it but so far nothing has been proposed.
    - arcanon 5y ago
      It seems to me that there is a divide of angular typescript apps that are about 3-5 years old and a new wave of react flow apps. Wonder what the stats are.
      - Zababa 5y ago
        That might be just my bubble, but I've never heard of anyone using Flow, especially with React, whereas I often hear about React with TypeScript.
eropple 5y ago
If we're wild-assed guessing, mine is that TypeScript eventually merges with JavaScript. It is a wisely designed set of optional type constraints that aren't incompatible with JS proper. Seeing as how every conformant TypeScript compiler is also a conformant JavaScript compilers, the split is pretty small and eating one's vegetables is good for you. (With one nit: TypeScript enums are weird and while they work in JavaScript ways they are weird and might be best off being rethought, even if it's backwards-incompatible.)
- cryptica 5y ago
  If TypeScript becomes natively interpreted (instead of transpiled), I might actually consider using it for my personal projects. In the meantime, I don't use it because I cannot stand the build, bundling step and the problematic debugging experience with source mapping (and difficulty to debug production errors where source maps are not available). If you write code correctly with loose coupling and good tests, static typing only provides marginal benefits.
  - eropple 5y ago
    Your last sentence is writing a very large check that I'm not confident at all you can cash. Static typing obviates most runtime type checking, which your module boundaries need to be doing (and exercising in tests). Libraries like runtypes deal with the last mile of it by generating runtime type guards that also project back into the static type system. This removes the need for entire classes of tests, as well as many of those handling intra-module transforms. It's telling that the people doing some of the best work in, say, Ruby are in on both tooling like Sorbet and libraries like dry-types/dry-struct -- because the benefits are significant in terms of minimizing engineering risk. Static typing is also standardized and machine-readable documentation. This can't be understated. Human-written documentation rots with changes. The guarantees at module level from your static types does not. Particularly when gradually introduced, these are significant force multipliers. If you want to take on the additional risk for your toy projects, more power to you (I sometimes write Ruby when doing something that doesn't matter) but I certainly find those benefits significantly more than "marginal" if anyone else ever has to deal with my code--including future-me.
frosted-flakes 5y ago
TypeScript and JavaScript are the same language, and JS is definitely not going anywhere.

by xfitm3 5y ago

Zababa 5y ago

I think Typescript is here to stay, way more than Coffeescript was. On the other hand, I wonder if there's not a missed opportunity by compiling TS to JS. You lose all the type information that could be used to optimize the code.

arcanon 5y ago
How so? Coffeescript was mostly absorbed by JS, a true success story. The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. OP might be on to something, not wanting to waste time chasing trend n-1
- mcphage 5y ago
  > The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. What do you see them moving to?
  - arcanon 5y ago
    Linky: https://www.google.com/amp/s/startfunction.com/deno-will-stop-using-typescript/%3famp https://www.google.com/amp/s/startfunction.com/deno-will-sto...
    - Zababa 5y ago
      This is just a Deno-specific internal thing due to tsc being too slow for their specific case. Deno itself can read and execute TS code and they aren't planning on dropping that.
      - arcanon 5y ago
        Right, they just wouldn’t use it themselves.
        Zababa 5y ago
        In the original design doc: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... > Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
- Zababa 5y ago
  Intertia. TS is way more popular than Coffeescript ever was, so there will be more code to maintain, and the network effect applies here. > The cutting edge JS ppl are moving away from TS right now, at least some of the ones I follow on twitter seem to be over it. Who are these people, why are they moving away from it? > OP might be on to something, not wanting to waste time chasing trend n-1 If you need static typing for JS now, TS is your best bet. You can also wait N years for TC-39 to add it but so far nothing has been proposed.
  - arcanon 5y ago
    It seems to me that there is a divide of angular typescript apps that are about 3-5 years old and a new wave of react flow apps. Wonder what the stats are.
    - Zababa 5y ago
      That might be just my bubble, but I've never heard of anyone using Flow, especially with React, whereas I often hear about React with TypeScript.

eropple 5y ago

If we're wild-assed guessing, mine is that TypeScript eventually merges with JavaScript. It is a wisely designed set of optional type constraints that aren't incompatible with JS proper. Seeing as how every conformant TypeScript compiler is also a conformant JavaScript compilers, the split is pretty small and eating one's vegetables is good for you. (With one nit: TypeScript enums are weird and while they work in JavaScript ways they are weird and might be best off being rethought, even if it's backwards-incompatible.)

cryptica 5y ago
If TypeScript becomes natively interpreted (instead of transpiled), I might actually consider using it for my personal projects. In the meantime, I don't use it because I cannot stand the build, bundling step and the problematic debugging experience with source mapping (and difficulty to debug production errors where source maps are not available). If you write code correctly with loose coupling and good tests, static typing only provides marginal benefits.
- eropple 5y ago
  Your last sentence is writing a very large check that I'm not confident at all you can cash. Static typing obviates most runtime type checking, which your module boundaries need to be doing (and exercising in tests). Libraries like runtypes deal with the last mile of it by generating runtime type guards that also project back into the static type system. This removes the need for entire classes of tests, as well as many of those handling intra-module transforms. It's telling that the people doing some of the best work in, say, Ruby are in on both tooling like Sorbet and libraries like dry-types/dry-struct -- because the benefits are significant in terms of minimizing engineering risk. Static typing is also standardized and machine-readable documentation. This can't be understated. Human-written documentation rots with changes. The guarantees at module level from your static types does not. Particularly when gradually introduced, these are significant force multipliers. If you want to take on the additional risk for your toy projects, more power to you (I sometimes write Ruby when doing something that doesn't matter) but I certainly find those benefits significantly more than "marginal" if anyone else ever has to deal with my code--including future-me.

frosted-flakes 5y ago

TypeScript and JavaScript are the same language, and JS is definitely not going anywhere.