Live data from Hacker News

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

101–110 of 226 posts

Re: Announcing TypeScript 2.1

#101
Dear TS authors:

Thank you (!) for your amazing contributions. TS is the best new thing in tech.

That said:

Your linguistic genius is way ahead of the tooling.

I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...

But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy.

It was difficult to grasp the difference between AMD and other paradigms. I still have problems with circular dependencies, or rather, things happening before modules are loaded.

Here's one pain point:

Creating a static attribute on a class and initializing it right there, as in:

class A { static b:B = new B(); }

Means that 'new B()' will get executed right when that module is loaded, possibly before the module containing B is loaded.

It's ugly, mechanical - but it's not a 'fine point'. I think these are the kinds of issues which are more likely to hold people back, as opposed to the lack of some rather fancy new paradigms such as 'Mapped Types'.

Anyhow, keep up the good work. Lovin't it.

Re: Announcing TypeScript 2.1

#102
post #15

Typescript is a game changer for any serious project. Never going back to plain JS.

Concur.

I am basically 'anti religious' when it comes to software.

So many people argue back and forth about this or that, and 80% of arguments are academic and effete (this is what I mean be 'religious').

But I'm a big supporter of TS because I believe 'it makes sense' on almost every level.

I'm not a 'big supporter' of many things at all, if any.

I understand the limitations, and that it enforces some things for which we may want more flexibility ... but overall, I have to say I can't think of any reason ever to use JS again.

My hope is that V8 etc. build engines to run TS directly as opposed to having to transpile.

Re: Announcing TypeScript 2.1

#103
post #66

Are there any plans to catch something like this: function f(x: any): T { return x }

That would defeat the point of 'any', right? It's for variables that you want to allow to do anything (including be a T) without the compiler complaining. If you don't want that behaviour, don't given x 'any' type. In that case there I'd probably use '{}' instead, and then use type guards ( https://www.typescriptlang.org/docs/handbook/advanced-types.... to convince TypeScript that it's a T (whatever that means).

tslint has a rule to prohibit the use of any. maybe this is worth an option for tsc

Re: Announcing TypeScript 2.1

#104
post #23

Earlier quoted context omitted.

I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.

Where do you perceive the C#-ness of TS coming from? TS and Flow are ~90% identical (most programs accepted by one would be accepted by the other) and TS adds only a few purely optional syntactic features (namespace, enum) that are widely found in other languages.

Might be referring to or var smt = new Smt(); or the use of ? etc.

Re: Announcing TypeScript 2.1

#105

Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts

I haven't worked too much with Haskell, but I've spent some time with Scala - they have pretty advanced type systems.

Typescript can't match them 100%, but it's getting there. e.g. It doesn't have type variance, but it does have f-bounded polymorphism (which is unheard of in most mainstream languages). The language is powerful enough to build your own constructs. I maintain a Typescript library[1] that emulates Scala options/trys/futures.

For day-to-day work, Typescript is a joy to work with. I describe it to others as the child of Scala and Ruby - pretty powerful type system but with a large community.

[1] https://github.com/jiaweihli/monapt

Re: Announcing TypeScript 2.1

#106

Question: Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser! As an example, the flow checker will read the annotations from `function f(n/ :number /, s/ :string /) { ... }` but since they are commented in the source code your JS engi…

Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps:

1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything)

    $ npm install --save-dev babel-plugin-transform-flow-strip-types
Then update your `.babelrc`:

    { plugins: ["transform-flow-strip-types"] }
2. Setting up with ESLint

    $ npm install --save-dev eslint-plugin-flowtype-errors
Then update your `.eslintrc`:

    { plugins: ["flowtype-errors"] }

Then just install `flow-bin` and create an empty `.flowconfig` file in the root of your repo and you're done. Now you have Babel compiling your code the same as always and you can use the Flow type syntax, and with ESLint you probably already have your editor all setup to show you warnings.

We're trying to integrate more with tools like this so you don't have to go changing your entire workflow. It shouldn't be so hard to add types to your existing JavaScript code.

Re: Announcing TypeScript 2.1

#107
post #16

So can I finally banish babel from my build steps?

I did while 2.1 was an RC. It has worked flawlessly and I haven't looked back. Build and minification is still a pain though...

Try webpack, it's fast and the configuration is nearly declarative.

You can also create a separate build task to run a smoke test by directly calling the ts compiler to compile your code (skipping pre- and post- build steps). This was a lot faster than I expected.

Re: Announcing TypeScript 2.1

#109

Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts

They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript.

In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.

Re: Announcing TypeScript 2.1

#110
post #104

Earlier quoted context omitted.

Where do you perceive the C#-ness of TS coming from? TS and Flow are ~90% identical (most programs accepted by one would be accepted by the other) and TS adds only a few purely optional syntactic features (namespace, enum) that are widely found in other languages.

Might be referring to or var smt = new Smt(); or the use of ? etc.

Those all exist in Flow as well.

I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.

Post reply on HN