15 ms·

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminated unions where the code and objects look like what you'd do in vanilla JS, but checked (and requiring the class to have a specific structure seems fine as limitations go). I get how folks coming from "natively" static type systems could find all this weird, but I think by targeting "JS but with better checks" instead of a more fundamental redesign, the TypeScript crew have managed to build something that can get traction where other efforts have not.

cryptica 7y ago
I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.
- nicoburns 7y ago
  Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.
  - cryptica 7y ago
    Is TypeScript low-cost? Most TS projects I've worked on had at least a 10 to 30 seconds build waiting time per iteration. This means that every time I make a change and run the tests, I need to wait 10 to 30 seconds. With my iterative test-driven approach, I probably iterate about once every minute on average (also, my development iteration time gets faster as I become more experienced in the project). So 30 seconds represents 50% of my total development time. Meaning that I could have written 50% more tests or 50% more features in the same amount of time. And that's not even accounting for my loss of focus incurred as a result of waiting 30 seconds to see the result of my code change. By the time I see the result, the concept in my mind is not as fresh as it was 30 seconds earlier.
    - Fannon 7y ago
      Are you aware of tsc options like --watch and --incremental ? Combined with other live-reloading tools like nodemon or jest --watch you can have almost the same speed of your development-test-run-debug loops as in plain JS. But you do gain an additional instant feedback channel from the compiler.
  - kjtekn 7y ago
    No longer enjoying programming is a cost nobody can afford to pay. When I read the long list of c#, I mean typescript documentation, it gives me PTSD from c# and java, which people used to hate here, but now suddenly like and let me tell you it has nothing to do with microsoft social engineering.
    - BorisTheBrave 7y ago
      Devs should enjoy writing trivial tests? Heaven forbid businesses might care how quickly something is delivered? Let us know when you are willing join the rest of us in the real world.
    - TomMarius 7y ago
      I also used to think TS is like C#. Huge mistake. Try to approach it from a functional angle. The TS compiler code does not use the class keyword.
- DonHopkins 7y ago
  Do your JavaScript tests inform your IDE how to do code highlighting and completion and refactoring?
  - cryptica 7y ago
    My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in the best way possible without regard for the previous structure of the code (which may no longer be relevant anyway; there is usually a good reason why we do refactorings in the first place! It's rarely just about renaming things). I have many stories on the subject but most recently I did a significant refactoring for a JavaScript project (a popular open source library I created) to move from callbacks to async/await and was able to re-use pretty much all of the existing integration test logic with only aesthetic changes (to account for the new async/await API). When I finished the refactoring, I had modified at least 70% of the entire source code of the project and I took it as an opportunity to make significant structural changes to my code to align with the new async/await flow in the most optimal way possible. This kind of big refactoring would have made code highlighting completely redundant and would have prevented me from looking at the problem with a fresh mind and taking into account the new features offered by async/await. It was a very successful refactoring; no new issues were uncovered after the point that I managed to get all the original tests passing again and the code was a lot simpler than before. I think TS has a way of locking down old structures in a way that make it sub-optimal in the long run. Feature-oriented tests are by far the best way to ensure that product quality is maintained after a refactoring IMO.
    - the_gipsy 7y ago
      I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.
- redmorphium 7y ago
  Some Typescript value added: - Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain. - Better tooling: autocomplete, more robust auto-refactoring - Elimination of an entire class of bugs. This class may include: 1. `Cannot read property 'foo' of undefined` 2. forgeting a case in a switch statement 3. `'foo' is not a function` 4. in general, your code receiving data that isn't laid out in a way you expected (Property typos is one within this class of bugs, but it is not all of it) Yes tests catch these bugs as well. But tests are also manually written. And often not written at all. A compiler makes these (mundane) sanity checks automatic and mandatory. --- Typescript's slogan is "JavaScript that scales" because static typing improves: dev documentation (via types living inside the code) and dev tooling (refactoring and autocomplete), both of which help immensely as a project grows in age (devs become forgetful), team size (new developers get lost), and convolutedness (e.g. tech debt).
  - kjtekn 7y ago
    Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know! auto-refactoring.. yeah we all trust that. Until you come to the boundaries where all the types don't exist, like from the client to the server, to the database via its message system, etc. All the stuff coming in and out of your code is untyped. Autocomplete works without typescript, even if it uses "the typescript engine". The types aren't needed. Eliminates an entire class of bugs that nobody has ever had a problem with.
    - eatonphil 7y ago
      > All the stuff coming in and out of your code is untyped. Until you automate building TypeScript definitions from your external code. We do this to varying degrees and are always trying to improve.
- lscharen 7y ago
  If TypeScript is used against bog-standard JS code, I can definitely appreciate your point. For me, TypeScript really started to shine once I started taking advantage its generic support, higher-level utility types like Pick<> and Optional<> (and really anything involving keyof), and creating static type checks via the unknown and never types. This is especially effective when working on legacy JS code bases where unit tests and other good engineering principles were not used well, or at all.
- vhakulinen 7y ago
  > My JavaScript tests catch typoed property names every time. My typescript compiler catches typoed property names every time. > I can't remember the last time I merged code with a typo in a property name. I can't remember the last time my newly written code made it into the runtime/browser with a typo in a property name. > ...if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with. The types are much more than just property names.
ketzo 7y ago
Yup. Rather than bringing 100,000 devs from one typed language to another, Typescript brings 1,000,000 devs from untyped to typed.
- bt4u 7y ago
  There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed
  - Sharlin 7y ago
    This is just a question of semantics. In mainstream programming language jargon it’s ”dynamically typed”, while in (applied) type theory it’s ”untyped” or, perhaps more accurately ”monotyped” or ”unityped”, because types are fundamentally invariants of a program that can be verified without executing it.
    - bt4u 7y ago
      Yeah why bother using correct terminology, it's just semantics. Plus is minus. Compiler is interpreter. Up is down. Leg is arm. Let's all just use our own personal definition of things, it doesn't matter Dynamic typing is not "untyped" in formal theory, I have no idea where you got that from
  - heavenlyblue 7y ago
    There’s always that “intellectual” who would say something smart while being absolutely wrong.
    - bt4u 7y ago
      Sure. But I'm not wrong
kazinator 7y ago
If you can pass a Cat to a Dog function, where is the better checking? That would be one of the hello-world test cases for a type checker bolted on to a dynamic language. That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.
- MaulingMonkey 7y ago
  Note that you can only pass Cat to a Dog function if: * All fields of Dog are also present in Cat, with compatible type signatures * All functions of Dog are also present in Cat, with comaptible type signatures "compatible type signatures" does seem to leave some suprising co/contravariance holes still when using wider union types, but C#/Java arrays also have co/contravariance holes and we don't automatically write off their entire type systems because of it. Or, well, at least I don't ;). As a meaningless point of ancedata: Making these types sufficiently equivalent to fall through this type safety hole appears to be rare enough that I've never done so by accident - allowing me to be suprised by the article's example of passing a class Cat to a class Dog-accepting function being legal. While typescript has never been my primary dayjob, it's been a significant secondary part of my dayjob and hobby junk. (EDIT: Minor clarifications)
  - carlmr 7y ago
    C# has a great type system, but everything has ToString() and sometimes that doesn't output something sensible, and gets implicitly converted, leading to garbage. Still much better than working in C or some other weakly typed languages.
  - Kinrany 7y ago
    Another example of a hole: https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB2wBOBTAti+AXFToG8AoaaAS0VQ2wAoAPALmngFc0AjXASkZfdwOIkyAM2jUsATwAOKAPaja0AIQBeFdADkvDkg2cBQoVgAWSWQHcmKSwFEkZpNQAGAEny0AvmRhhobyTLy0J4ANEyyWNC+2rhOnADcgiQehEnQqFjMSPDB0ADU0ACMicmEKYTkOEjCYMAo0ADKWEgIyOiYVQZkFO00DEysOtAAPtAQzeQA5twDfEiJ5cLMiFiksjnkbVRYdIzjSFNhm5QduIxNLT3bXDyD-EQkGVkbV6dIAHTHvTu0CWWpAHoAdA7A5GIUAEwAZm8UTGE3gkzC8AicJiSEIQOgTlaJ2wsWgABNZCgYCjIqQ0FIQN9ulUanVsRdcd9YoRgOsILIae8QLJJtQvttqBpIVCNMjrHBXvjHJx5fFoIQgA https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB...
Findeton 7y ago
As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using/developing an input validation library for the backend in Typescript (https://github.com/StrontiumJS/Framework/ https://github.com/StrontiumJS/Framework/) that is composable and also returns the correct type in one go. We used a lot of try catches for that, but that makes validation slow. So we started using "maybe promises" which are similar to Scala's Futures with Success/Failure. But the fact you don't have pattern matching in Typescript like in Scala makes it a bit ugly.
- gazarullz 7y ago
  You should try using computed propeties, it's the closest/cleanest way to pattern matching until tc39 will pass the pending proposal.
- firethief 7y ago
  Have you considered OCaml with BuckleScript or js_of_ocaml? The language that inspired Rust's nods to FP can be compiled to mostly-idiomatic Javascript.
- Shacklz 7y ago
  Pattern matching is definitely something I also miss. For input validation and Optional/Either types, io-ts/fp-ts (https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts) fulfill my needs perfectly, especially io-ts is something I can't recommend enough. Saved me so many headaches from sudden breaking changes in APIs we consume.
- Fannon 7y ago
  Pattern matching seems to be a current proposal, also driven by Microsoft: https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
blobs 7y ago
> TypeScript crew have managed to build something that can get traction where other efforts have not. You mean Microsoft managed to get traction? It seems most TS proponents don't realize TS is a success because they fell for smart marketing and serious money behind the project, not because it's a better language than 'other efforts' like for example Purescript or Dart. But every comment I make against TS seems futile. TS proponents defend their little language very fiercely regardless of all the flaws it has. It's almost worth a study how Microsoft managed to do that. Overall a real pity, because there are so many better options and ideas for those who want static typing. TS is actually the worse choice IMAO.
- TomMarius 7y ago
  They did it by solving a great pain of a very large amount of people. Not many of these people would have been able to use Dart or PureScript.
- DonHopkins 7y ago
  >It's almost worth a study how Microsoft managed to do that. It's almost as if Microsoft learned the techniques of linguistic evangelism from Sun when they studied the ideas behind Java to design C#, but they left out the anti-linguistic-miscegenation Java-supremacist ideals of "100% Pure Java [TM]" when they made it easy to integrate other mongrel languages with COM and P/Invoke. https://news.ycombinator.com/item?id=19571635 https://news.ycombinator.com/item?id=19571635
- tigershark 7y ago
  Typescript unlike Dart, Purescript, Fable and BuckleScript is a superset of JavaScript so you don’t have to change anything in your existing JavaScript project to start using Typescript. Also JavaScript interop is a breeze and a huge percentage of the libraries have already typescript binding and it’s a huge advantage compared to using the aforementioned languages.
mirekrusin 7y ago
Nominal types for classes feels like a better decision in flow, no need to mangle with phantom private props which is not the place you want to make this decision (when you call there could be this decision made but I can’t think for use case, making this decision at definition is too rigid and makes less sense).
cloverich 7y ago
Structural typing has the benefit of making it easier to code to an interface and reminds me of Go. If you have a function that requires a method off a class (say, `poop`), then rather than declaring it to accept `Cat | Dog` (or overload it, in e.g. Java), you code it to accept an object with a single function (`pooper: { poop: VoidFunction}`). Then anything that implements it can use it, testing is typed and easy, and changing the class is less likely to affect the consuming method. Its such a powerful pattern, I'm a bit surprised to see so much negativity about it. I'm aware there's alternatives and reasoned opinions, but I bet a significant number of people have never seen or programmed in this style and aren't aware of what they are missing. For me, I can't imagine using another typed language that doesn't support implicit interfaces in this manner.

cryptica 7y ago

I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

nicoburns 7y ago
Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.
- cryptica 7y ago
  Is TypeScript low-cost? Most TS projects I've worked on had at least a 10 to 30 seconds build waiting time per iteration. This means that every time I make a change and run the tests, I need to wait 10 to 30 seconds. With my iterative test-driven approach, I probably iterate about once every minute on average (also, my development iteration time gets faster as I become more experienced in the project). So 30 seconds represents 50% of my total development time. Meaning that I could have written 50% more tests or 50% more features in the same amount of time. And that's not even accounting for my loss of focus incurred as a result of waiting 30 seconds to see the result of my code change. By the time I see the result, the concept in my mind is not as fresh as it was 30 seconds earlier.
  - Fannon 7y ago
    Are you aware of tsc options like --watch and --incremental ? Combined with other live-reloading tools like nodemon or jest --watch you can have almost the same speed of your development-test-run-debug loops as in plain JS. But you do gain an additional instant feedback channel from the compiler.
- kjtekn 7y ago
  No longer enjoying programming is a cost nobody can afford to pay. When I read the long list of c#, I mean typescript documentation, it gives me PTSD from c# and java, which people used to hate here, but now suddenly like and let me tell you it has nothing to do with microsoft social engineering.
  - BorisTheBrave 7y ago
    Devs should enjoy writing trivial tests? Heaven forbid businesses might care how quickly something is delivered? Let us know when you are willing join the rest of us in the real world.
  - TomMarius 7y ago
    I also used to think TS is like C#. Huge mistake. Try to approach it from a functional angle. The TS compiler code does not use the class keyword.
DonHopkins 7y ago
Do your JavaScript tests inform your IDE how to do code highlighting and completion and refactoring?
- cryptica 7y ago
  My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in the best way possible without regard for the previous structure of the code (which may no longer be relevant anyway; there is usually a good reason why we do refactorings in the first place! It's rarely just about renaming things). I have many stories on the subject but most recently I did a significant refactoring for a JavaScript project (a popular open source library I created) to move from callbacks to async/await and was able to re-use pretty much all of the existing integration test logic with only aesthetic changes (to account for the new async/await API). When I finished the refactoring, I had modified at least 70% of the entire source code of the project and I took it as an opportunity to make significant structural changes to my code to align with the new async/await flow in the most optimal way possible. This kind of big refactoring would have made code highlighting completely redundant and would have prevented me from looking at the problem with a fresh mind and taking into account the new features offered by async/await. It was a very successful refactoring; no new issues were uncovered after the point that I managed to get all the original tests passing again and the code was a lot simpler than before. I think TS has a way of locking down old structures in a way that make it sub-optimal in the long run. Feature-oriented tests are by far the best way to ensure that product quality is maintained after a refactoring IMO.
  - the_gipsy 7y ago
    I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.
redmorphium 7y ago
Some Typescript value added: - Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain. - Better tooling: autocomplete, more robust auto-refactoring - Elimination of an entire class of bugs. This class may include: 1. `Cannot read property 'foo' of undefined` 2. forgeting a case in a switch statement 3. `'foo' is not a function` 4. in general, your code receiving data that isn't laid out in a way you expected (Property typos is one within this class of bugs, but it is not all of it) Yes tests catch these bugs as well. But tests are also manually written. And often not written at all. A compiler makes these (mundane) sanity checks automatic and mandatory. --- Typescript's slogan is "JavaScript that scales" because static typing improves: dev documentation (via types living inside the code) and dev tooling (refactoring and autocomplete), both of which help immensely as a project grows in age (devs become forgetful), team size (new developers get lost), and convolutedness (e.g. tech debt).
- kjtekn 7y ago
  Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know! auto-refactoring.. yeah we all trust that. Until you come to the boundaries where all the types don't exist, like from the client to the server, to the database via its message system, etc. All the stuff coming in and out of your code is untyped. Autocomplete works without typescript, even if it uses "the typescript engine". The types aren't needed. Eliminates an entire class of bugs that nobody has ever had a problem with.
  - eatonphil 7y ago
    > All the stuff coming in and out of your code is untyped. Until you automate building TypeScript definitions from your external code. We do this to varying degrees and are always trying to improve.
lscharen 7y ago
If TypeScript is used against bog-standard JS code, I can definitely appreciate your point. For me, TypeScript really started to shine once I started taking advantage its generic support, higher-level utility types like Pick<> and Optional<> (and really anything involving keyof), and creating static type checks via the unknown and never types. This is especially effective when working on legacy JS code bases where unit tests and other good engineering principles were not used well, or at all.
vhakulinen 7y ago
> My JavaScript tests catch typoed property names every time. My typescript compiler catches typoed property names every time. > I can't remember the last time I merged code with a typo in a property name. I can't remember the last time my newly written code made it into the runtime/browser with a typo in a property name. > ...if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with. The types are much more than just property names.

ketzo 7y ago

Yup. Rather than bringing 100,000 devs from one typed language to another, Typescript brings 1,000,000 devs from untyped to typed.

bt4u 7y ago
There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed
- Sharlin 7y ago
  This is just a question of semantics. In mainstream programming language jargon it’s ”dynamically typed”, while in (applied) type theory it’s ”untyped” or, perhaps more accurately ”monotyped” or ”unityped”, because types are fundamentally invariants of a program that can be verified without executing it.
  - bt4u 7y ago
    Yeah why bother using correct terminology, it's just semantics. Plus is minus. Compiler is interpreter. Up is down. Leg is arm. Let's all just use our own personal definition of things, it doesn't matter Dynamic typing is not "untyped" in formal theory, I have no idea where you got that from
- heavenlyblue 7y ago
  There’s always that “intellectual” who would say something smart while being absolutely wrong.
  - bt4u 7y ago
    Sure. But I'm not wrong

kazinator 7y ago

If you can pass a Cat to a Dog function, where is the better checking? That would be one of the hello-world test cases for a type checker bolted on to a dynamic language. That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

MaulingMonkey 7y ago
Note that you can only pass Cat to a Dog function if: * All fields of Dog are also present in Cat, with compatible type signatures * All functions of Dog are also present in Cat, with comaptible type signatures "compatible type signatures" does seem to leave some suprising co/contravariance holes still when using wider union types, but C#/Java arrays also have co/contravariance holes and we don't automatically write off their entire type systems because of it. Or, well, at least I don't ;). As a meaningless point of ancedata: Making these types sufficiently equivalent to fall through this type safety hole appears to be rare enough that I've never done so by accident - allowing me to be suprised by the article's example of passing a class Cat to a class Dog-accepting function being legal. While typescript has never been my primary dayjob, it's been a significant secondary part of my dayjob and hobby junk. (EDIT: Minor clarifications)
- carlmr 7y ago
  C# has a great type system, but everything has ToString() and sometimes that doesn't output something sensible, and gets implicitly converted, leading to garbage. Still much better than working in C or some other weakly typed languages.
- Kinrany 7y ago
  Another example of a hole: https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB2wBOBTAti+AXFToG8AoaaAS0VQ2wAoAPALmngFc0AjXASkZfdwOIkyAM2jUsATwAOKAPaja0AIQBeFdADkvDkg2cBQoVgAWSWQHcmKSwFEkZpNQAGAEny0AvmRhhobyTLy0J4ANEyyWNC+2rhOnADcgiQehEnQqFjMSPDB0ADU0ACMicmEKYTkOEjCYMAo0ADKWEgIyOiYVQZkFO00DEysOtAAPtAQzeQA5twDfEiJ5cLMiFiksjnkbVRYdIzjSFNhm5QduIxNLT3bXDyD-EQkGVkbV6dIAHTHvTu0CWWpAHoAdA7A5GIUAEwAZm8UTGE3gkzC8AicJiSEIQOgTlaJ2wsWgABNZCgYCjIqQ0FIQN9ulUanVsRdcd9YoRgOsILIae8QLJJtQvttqBpIVCNMjrHBXvjHJx5fFoIQgA https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB...

Findeton 7y ago

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using/developing an input validation library for the backend in Typescript (https://github.com/StrontiumJS/Framework/ https://github.com/StrontiumJS/Framework/) that is composable and also returns the correct type in one go. We used a lot of try catches for that, but that makes validation slow. So we started using "maybe promises" which are similar to Scala's Futures with Success/Failure. But the fact you don't have pattern matching in Typescript like in Scala makes it a bit ugly.

gazarullz 7y ago
You should try using computed propeties, it's the closest/cleanest way to pattern matching until tc39 will pass the pending proposal.
firethief 7y ago
Have you considered OCaml with BuckleScript or js_of_ocaml? The language that inspired Rust's nods to FP can be compiled to mostly-idiomatic Javascript.
Shacklz 7y ago
Pattern matching is definitely something I also miss. For input validation and Optional/Either types, io-ts/fp-ts (https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts) fulfill my needs perfectly, especially io-ts is something I can't recommend enough. Saved me so many headaches from sudden breaking changes in APIs we consume.
Fannon 7y ago
Pattern matching seems to be a current proposal, also driven by Microsoft: https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching

blobs 7y ago

> TypeScript crew have managed to build something that can get traction where other efforts have not. You mean Microsoft managed to get traction? It seems most TS proponents don't realize TS is a success because they fell for smart marketing and serious money behind the project, not because it's a better language than 'other efforts' like for example Purescript or Dart. But every comment I make against TS seems futile. TS proponents defend their little language very fiercely regardless of all the flaws it has. It's almost worth a study how Microsoft managed to do that. Overall a real pity, because there are so many better options and ideas for those who want static typing. TS is actually the worse choice IMAO.

TomMarius 7y ago
They did it by solving a great pain of a very large amount of people. Not many of these people would have been able to use Dart or PureScript.
DonHopkins 7y ago
>It's almost worth a study how Microsoft managed to do that. It's almost as if Microsoft learned the techniques of linguistic evangelism from Sun when they studied the ideas behind Java to design C#, but they left out the anti-linguistic-miscegenation Java-supremacist ideals of "100% Pure Java [TM]" when they made it easy to integrate other mongrel languages with COM and P/Invoke. https://news.ycombinator.com/item?id=19571635 https://news.ycombinator.com/item?id=19571635
tigershark 7y ago
Typescript unlike Dart, Purescript, Fable and BuckleScript is a superset of JavaScript so you don’t have to change anything in your existing JavaScript project to start using Typescript. Also JavaScript interop is a breeze and a huge percentage of the libraries have already typescript binding and it’s a huge advantage compared to using the aforementioned languages.

mirekrusin 7y ago

Nominal types for classes feels like a better decision in flow, no need to mangle with phantom private props which is not the place you want to make this decision (when you call there could be this decision made but I can’t think for use case, making this decision at definition is too rigid and makes less sense).

cloverich 7y ago

Structural typing has the benefit of making it easier to code to an interface and reminds me of Go. If you have a function that requires a method off a class (say, `poop`), then rather than declaring it to accept `Cat | Dog` (or overload it, in e.g. Java), you code it to accept an object with a single function (`pooper: { poop: VoidFunction}`). Then anything that implements it can use it, testing is typed and easy, and changing the class is less likely to affect the consuming method. Its such a powerful pattern, I'm a bit surprised to see so much negativity about it. I'm aware there's alternatives and reasoned opinions, but I bet a significant number of people have never seen or programmed in this style and aren't aware of what they are missing. For me, I can't imagine using another typed language that doesn't support implicit interfaces in this manner.