[fernandezpablo]

I disagree. Typescript is an excellent example of an optional static type system that works great. It has none of the 3 problems the OP describes: it's fast, it nicely encompasses the whole language and the Definitely Typed repository includes a TON of 3rd party library type definitions.

[softawre]

How big is your Typescript project? Because when I read the first paragraph of this I cringed and knew where they were going.

We have a medium sized Typescript app (~100k lines), and it takes 7-10 seconds to transpile to JS.

Whenever a change is made, that is 7-10 seconds the watch command is running and I'm not testing my changes in the webapp.

In fact, a slow running grunt watch is why I'm on HN right now in the first place.

[fernandezpablo]

That's a ton, you're probably not using typescript incremental compilation feature but recompiling your whole codebase instead. Even in that case, 7 seconds for compiling a 100k LOC code base is not even close to what I call "slow".

[jerven]

Its slower than my java build with 300000 lines in it. More than 0.5 seconds is slow.

[pjmlp]

> Whenever a change is made, that is 7-10 seconds the watch command is running and I'm not testing my changes in the webapp.

Compared with C and C++ build times which are measured in minutes or even hours, 10s is nothing.

[copperx]

I wasn't aware that C and C++ compilers were dog-slow. Is that because of the complexity of the language in the case of C++ compilers?

[chubot]

A lot of the bottleneck is the header structure: the size of the translation units (.c files with headers expanded transitively) is often quadratic with respect to overall codebase size.

If you fix that, then linking can take a long time too. (Not sure on the details, but it's a "global" algorithm to fix up all the pointer offsets)

Incremental builds will be slow if you structure your code in such a way that you often have to touch a header file, and that header file requires recompiling all translation units.

In short, you have to be super careful about structuring your code in C/C++ if you want fast build times, and approximately zero of the industrial codebases I've seen do this. (Well there was one, but it was all written by a single person, which is not surprising.)

[JoeAltmaier]

Huh? My 100,000 lines of code takes seconds.

[Matthias247]

That also depends massively on the used libraries and the structure of the code. A 100kloc c file could build superfast. Whereas multiple c++ totalling about 10kloc that include use use lots of Boost stuff can take ages compared to that.

[pjmlp]

Try compiling a real big project, enterprise scale e.g. Linux kernel.

[maineldc]

The article's code base is also ~100K lines (of clojure) and the type checker runs for 2 mins, so it feels safe to say that Typescript's checking is an order of magnitude faster, right?

[softawre]

I guess so.

The who who recommended Webpack, I can't reply to you for some reason, though I will try it.

[spion]

Is that watching using `tsc -w` or watch(1) [1]

[1]: http://linux.die.net/man/1/watch

[carterehsmith]

"Whenever a change is made, that is 7-10 seconds the watch command is running"

Wait, is that 7-10 sec with "tsc --watch"? Or like, the whole shebang for the production build?

[rattray]

Have you tried using Webpack instead of grunt? I haven't tried it with TypeScript but it watches incrementally and might be a lot faster.

[masterj]

It's competitor from facebook (http://flowtype.org/) is also really fast during development as well, even for sweeping changes across big sections of the code base.

[rtpg]

agreed on TS, we're using it extensively in production to great effect.

I think TypeScript is an extremely impressive tool, and a great example of considering the current environment when designing. The type system can effectively capture pretty much all API designs that see use.

[smrtinsert]

Following some frustrations with cljs, I've gone to Typescript as well. Seems like it will be a more practical fit.