Hacker News Reader

Comment by fernandezpablo | Hacker News Reader

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.

View on HN

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.

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".

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

> 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.

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?

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.)

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

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.

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

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?

I guess so.

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

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

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

"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?

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.

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.

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.

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

Reply on news.ycombinator.com