18 ms·

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

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.

masterj 11y ago
It's competitor from facebook (http://flowtype.org/ http://flowtype.org/) is also really fast during development as well, even for sweeping changes across big sections of the code base.
rtpg 11y ago
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.
softawre 11y ago
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.
- maineldc 11y ago
  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 11y ago
    I guess so. The who who recommended Webpack, I can't reply to you for some reason, though I will try it.
- rattray 11y ago
  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.
- pjmlp 11y ago
  > 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 11y ago
    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 11y ago
      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 11y ago
    Huh? My 100,000 lines of code takes seconds.
    - pjmlp 11y ago
      Try compiling a real big project, enterprise scale e.g. Linux kernel.
    - Matthias247 11y ago
      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.
- spion 11y ago
  Is that watching using `tsc -w` or watch(1) [1] [1]: http://linux.die.net/man/1/watch http://linux.die.net/man/1/watch
- fernandezpablo 11y ago
  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 11y ago
    Its slower than my java build with 300000 lines in it. More than 0.5 seconds is slow.
- carterehsmith 11y ago
  "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?
smrtinsert 11y ago
Following some frustrations with cljs, I've gone to Typescript as well. Seems like it will be a more practical fit.

masterj 11y ago

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

rtpg 11y ago

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.

softawre 11y ago

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.

maineldc 11y ago
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 11y ago
  I guess so. The who who recommended Webpack, I can't reply to you for some reason, though I will try it.
rattray 11y ago
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.
pjmlp 11y ago
> 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 11y ago
  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 11y ago
    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 11y ago
  Huh? My 100,000 lines of code takes seconds.
  - pjmlp 11y ago
    Try compiling a real big project, enterprise scale e.g. Linux kernel.
  - Matthias247 11y ago
    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.
spion 11y ago
Is that watching using `tsc -w` or watch(1) [1] [1]: http://linux.die.net/man/1/watch http://linux.die.net/man/1/watch
fernandezpablo 11y ago
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 11y ago
  Its slower than my java build with 300000 lines in it. More than 0.5 seconds is slow.
carterehsmith 11y ago
"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?

smrtinsert 11y ago

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