
Porting 30K lines of code from Flow to TypeScript - munchor
https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/
======
tinyvm
I recently did the exact same job as the author of this post.

Migrating 15K LoC from JS to TS.

The author of Vue.JS also migrated Vue completely to Typescript.

At first I had major apprehension because of how much Microsoft generally
enforces things on developers.

It's well know that if you start using C# , your entire stack will generally
be MS based...(SQL Server, Azure etc... )

But after I did the migration , I was blown away by how confident and how much
flexibility I had when i was writing my code.

Even if I have been writing code with Java / C# for nearly a decade , nothing
has come close to Typescript in terms of productivity,flexibility and
confidence.

Having used Javascript since before Node.JS , I think the whole idea of having
to "transpile" my code to something or to respect some "rules" define by a
company with a reputation that wasn't really "all in open source" .

But after using Typescript on multiples projects , you just can't go back ,
it's incredible how well it's scale without enforcing anything on the
developers.

Hopefully , one day bootcamps will include Typescript in their trainings to
demonstrate how typings can solve maintainability issues...

~~~
sonnyblarney
"Even if I have been writing code with Java / C# for nearly a decade , nothing
has come close to Typescript in terms of productivity,flexibility and
confidence."

Same here.

Isn't this truly amazing?

Take a jangly language like JS, and add some typing for the compiler, which
forces you to write cleaner code in addition to all the compiler advantages
... combined with some really cool features and _bang_ a magical, pragmatic
language.

Aside for some script things for which Python is still a blessing, I'd chose
TS for everything else, at least to start.

It just has the right mix of flexibility and expressivity etc..

Though TS is an MS project, I suggest it really is quite different, it's 'open
from the start' kind of thing, you can have a loot at TSC internals. The team
seems to be fairly dynamic and responsive.

Typscript is my #1 favorite 'invention' of the last few years, I think it will
be around for a while, and I hope to see many more JS API's 'properly
documented' with the help of TS.

~~~
untog
The exception I'd add is that JavaScript's standard library is still very
weak. I find myself leaning on Lodash for functionality that would be built
into any other language.

Part of me would love for TS to build one out and add shims as part of the
transpilation process, but it would go miles out of the scope of what TS is
trying to do. And I love that (compared to Babel) TS has no plugins and
relatively few options.

~~~
sonnyblarney
This is a very good point.

I wish lodashy functions, and a few other things (Time?), were just integrated
into JS, in a thoughtful way ... as part of the standard lib. So they could
all be done in native code in the engine.

~~~
zachrose
I’m sympathetic to this point of view, but I find lodash to be too huge of an
API. Most of the collection methods can be done as a small _.reduce, and I
find the many method names and subtle distinctions to add more trivia than
they remove.

~~~
untog
The good news is that you can use lodash as an ES6 module, with any tree-shake
capable bundler stripping out all the crap. Absolutely agree it's not optimal
though.

------
evmar
They wrote: "The TypeScript compiler could theoretically perform bundle
optimizations based on types and you are missing on that by having a separate
emitter and type checker."

Actually, this isn't true, and it's a fundamental property of TypeScript. It's
actually the secret to being a TypeScript wizard, and the more you internalize
it, the more questions about TypeScript you can answer in advance. I go
through some others here:
[http://neugierig.org/software/blog/2016/04/typescript-
types....](http://neugierig.org/software/blog/2016/04/typescript-types.html)

It's an important property in part for exactly the reasons this author worries
about it -- it preserves the property always safe to type check and emit
separately.

It's so fundamental to TS that their bug tracker, when reporting a bug, has a
checkbox about whether your request violates this property, and if so they
will discard your bug.

~~~
munchor
Author here, I actually addressed this in a footnote linked directly to that
sentence you quoted.

EDIT: This is incorrect ^, I misread your comment at first.

Thank you for bringing this up, this makes me feel even better about using
Babel to emit code.

~~~
RussianCow
I might be missing something, but that sentence does not appear to have a
footnote, nor do any of the footnotes directly address the OP's comment.

~~~
munchor
Oops, you're right, I misunderstood the original comment.

------
spion
Even though I'm a huge TypeScript fan, I'm grateful for the existence of Flow.

Their focus on soundness has shown the TypeScript team that they should give a
lot more priority to getting the typesystem in a better shape over the years.
If Flow didn't exist, I doubt we'd be seeing many of the features in
TypeScript's --strict mode.

Plus, they were the first to develop some features like intersection types, or
even some of the advanced type transformations. Shame it was (at least
historically) a bit difficult to find them in the docs.

I'm hoping Flow can push TS to close up the remaining soundness gaps, and fix
up some of their features (sealed vs open types is much better than the
strange object literal checks in TS)

~~~
nojvek
Competition, even for open source projects is a great boon.

I really would hate for Facebook to kill off flow because Typescript is
popular.

Microsoft, as great as they are at OSS, they still have to answer to a chain
of Managers who are distant from the actual users of their software.

~~~
acifani
I actually think TS team is much closer to the community than Flow's. Just
look at the number of open and closed Issues on GitHub.

To me, Flow feels like something they needed in Facebook and they happened to
open source. Their main focus is still FB's internal use and the direction is
set by it.

TypeScript, on the other hand, does not feel like this at all. They truly put
the community first, or so I - and many others - feel like.

~~~
smt88
> _Flow feels like something they needed in Facebook and they happened to open
> source_

This is how most Facebook tools feel to me. It makes me afraid to use them.
React is possibly an exception, but again -- too afraid to use it because
Facebook's open-source offerings seemed to have only selfish goals in the past
and often seem to be full of important bugs.

------
seanwilson
Are there any people that have switched to TypeScript that still think
dynamically typed languages have advantages over statically typed ones? Even
for small projects with only me working on them, I find static typing saves me
a ton of time and dynamic features are very rarely required or useful. The
vast majority of bugs in my TypeScript programs collect around the places they
interface with untyped JavaScript code.

~~~
Jach
Does TypeScript let you build a program interactively as a living thing?
Example of what dynamic languages for the browser (ClojureScript) have been
doing for 5 years now:
[https://www.youtube.com/watch?v=KZjFVdU8VLI](https://www.youtube.com/watch?v=KZjFVdU8VLI)
Given that frontend work is so often an endless series of tweaks I don't know
how people stand doing anything big for a long duration the classic way of
edit -> compile (refresh) -> rebuild runtime state to look at what
changed/play around/test -> repeat.

~~~
basil-rash
To me that example doesn't look all that different from typical hot-reload
provided by webpack or similar. Can you tell me what I'm missing here?

~~~
Jach
I'm not familiar with webpack but in general hot reloading isn't quite the
same as dynamic redefinition, but can be close enough for many purposes. If
you can set up something approaching Java's hotswap (made even better by
JRebel) then perhaps the advantage is lessened.

~~~
porsager
You get dynamic redefinition with Wright[1][2] and chrome, and you can plug in
Typescript pretty easily.

In v2 currently under way, you can use es modules which gives you a much
better experience since you can reload a single file instead of an entire
bundle (always sub 100ms update times).

[1] [https://github.com/porsager/wright](https://github.com/porsager/wright)
[2]
[http://porsager.com/wright/example.mov](http://porsager.com/wright/example.mov)

------
funkaster
This is wrong: (from the article)

    
    
      function f(leaves: Array<Leaf>, aggregators: Array<Aggregator>): Array<MemsqlNode> {
        // The next line errors because you cannot concat aggregators to leaves.
        return leaves.concat(aggregators);
      }
    

That's just wrong, of course you can't concat aggregators and leaves! and
Typescript is OK to not accept it. If you want that to be ok, you could do
something like

    
    
      [].concat(leaves, aggregators)

~~~
munchor
Author here. I understand this example may be a little controversial. However,
from my point of view, if I annotate my function as returning an
`Array<MemsqlNode>` and `leaves.concat(aggregators)` can be cast to
`Array<MemsqlNode>`, then I don't see why I shouldn't be able to return this
in this function without verbose syntax or "tricks".

~~~
funkaster
it's not a trick. Yes, it can be casted, but you should be explicit about it.
AFAIK, the signature for the concat function is dependent on the array you're
using it, so in this case, it's Array<Leaves>. Even though concat returns a
new array, it is expecting the arguments to be of similar type. That's a
"safe" behavior and something I would expect. Auto-casting to the return type
(in this case) is something that I would not expect to happen, as it could be
the source of errors.

Doing [].concat(Array<A>, Array<B>) is fine, because you did not specify the
type of the array for the literal [], it's not a trick, in that case the type
should be Array<any>, but it's casted to Array<MemsqlNode>.

~~~
munchor
Right but isn't that effectively changing the runtime code (thus making it a
trick) in order to fix a type error? I don't know if the performance of
`a.concat(b)` is the same as `[].concat(a, b)`.

~~~
WorldMaker
The argument is that you have a potential type error in `a.concat(b)` that you
hadn't considered before in that code: If `a` is defined everywhere as
Array<Leaf> and you push() something to it that is not a Leaf you potentially
broke one of your own invariants somewhere else that uses `a`. In JS concat
happens in place and is a mass push, so the same general concept holds.

~~~
dunham
`concat` doesn't happen in place, it builds a new array:

    
    
        https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat

~~~
WorldMaker
Interesting. Then that should be a fixable bug in TS' lib files then.

~~~
WorldMaker
There's an issue mentioning it with a PR Welcome sign up:
[https://github.com/Microsoft/TypeScript/issues/27545](https://github.com/Microsoft/TypeScript/issues/27545)

~~~
WorldMaker
Ah, and there is at least one PR specifically for it:
[https://github.com/Microsoft/TypeScript/pull/25716](https://github.com/Microsoft/TypeScript/pull/25716)

------
gregwebs
What about the speed of type-checking? Flow is near-instant by keeping
everything live from the last check whereas TypeScript has always been much
slower.

Other than that aspect (which is very important!) I do think TypeScript is
likely a better choice if you use any third party libraries that already have
definitions available.

~~~
iamaelephant
I work on a >100KLOC Flow codebase and I can tell you the type checker is
anything but instant.

------
styfle
> unfortunately when you share a TypeScript playground link, those settings
> are not saved in the URL. For this reason, you have to manually set them
> when you open any TypeScript playground link from this article.

There is a much better typescript playground[0] that supports all options in
the permalink, for example see this link[1] that has `removeComments` enabled.

[0]: [https://typescript-play.js.org](https://typescript-play.js.org)

[1]: [https://typescript-
play.js.org/?removeComments=true#code/PTA...](https://typescript-
play.js.org/?removeComments=true#code/PTAEBUAsEsGdQMYHsC2KCmA7ALqA7tADaGgAmcAhgA5XoUBOAUMprEoegHSFIDmAFAHIocUBliwKvdPiIl66FBWiZBASgDcQA)

~~~
russley
There's also a good TypeScript playground clone here as well:

[https://agentcooper.github.io/typescript-
play/](https://agentcooper.github.io/typescript-play/)

~~~
styfle
This links to the same code as my post. You might just have an older bookmark.
See this PR[0].

[0]: [https://github.com/agentcooper/typescript-
play/pull/24](https://github.com/agentcooper/typescript-play/pull/24)

------
Roboprog
I wish Typescript had support for partial function application, since I use
that much more than “Executioner” classes.

Actually, I’ve moved away from OOP in general in my JavaScript, only as a last
resort. (Not going to put in long comment from tablet screen...)

~~~
paulddraper
Outside of type annotations, Typescript never supports syntax that isn't in an
ECMAScript standard or a popular proposal.

That said, there is a Stage 1 TC39 proposal for partial application.
[https://github.com/tc39/proposal-partial-
application](https://github.com/tc39/proposal-partial-application)

~~~
Roboprog
Thanks for the tip.

I have been using Ramda’s R.partial() function a bit, as well as some in-house
stuff (e.g. - to generate 0-arity event handlers), but this would be a very
helpful feature, particularly once IDE recognition becomes widespread.

Background: suite of related projects started in early 2015, ES5 on IE11 kind
of limitations... (recently started using a transpiler for syntactic sugar)

------
Waterluvian
I'm currently porting about 15k lines of my own JS to TS. There's something so
satisfying about finding all kinds of bugs through this process.

And what I love the most: anywhere that I absolutely positively don't want to
deal with it yet: `any`

------
sephoric
> Lower quality editor/IDE integrations (when compared to TypeScript)

This is one of my favorite aspects of TypeScript, the first-class support it
receives in Monaco Editor (part of VS Code) which is one of the reasons I also
chose first-class TypeScript support when making Autumn, since I could embed
Monaco right into it and get countless amazing IDE features for free.

> unfortunately, we had to change a very small amount of runtime code to fix
> some logic that TypeScript could not understand

Would be very curious what this is, I've only found maybe one or two things
TypeScript could not understand, and they were already under active
development in the Github repo.

~~~
_asummers
> countless amazing IDE features for free.

Is this just from LSP? Or are there extras that are built into VSCode?

~~~
rsimp
Ironically typescript doesn't have a supported language server from MS.
TSServer (in the typescript npm package) is language server-esque and that's
what VS Code plugs into. I believe the main language server for typescript is
maintained by sourcegraph.

VS Code is written in typescript though and the projects have a pretty nice
cadence of new features. Typescript is very much a first class citizen in VS
Code

~~~
int_19h
Pretty much anything that comes from Microsoft today that is a web app, or
uses the HTML for UI on the desktop (such as Electron apps), is likely to be
written in TS. Not even because there's some push to do so, but because people
who mostly write in C# and C++ find TS far more preferable.

(That, by the way, is one reason why you can trust that it's not going away
anytime soon.)

------
NoParking
Thanks for sharing that.

We've just started a new Node project where typing was one of the main drivers
and went through a similar thought process. We use Flow on our client code but
the positive chatter about TypeScript had made us wonder if we should re-think
that. We have similar thoughts on a lot of the trade-offs. Flow feels better
at inference but the TypeScript ecosystem is amazing.

We ended up sticking with Flow for consistency (and we don't want to migrate
the client right now). It's good to know that a migration isn't impossible if
we ever change our minds.

------
derekdahmer
Thanks for this writeup! We also chose Flow in 2016 for the exact same reasons
you listed.

We aren't planning on switching anytime soon because we also are using Relay
which generates flow types for our GraphQL queries - but its good to know its
doable if we need to.

~~~
eliperkins
Relay supports generating Typescript types for queries as of v1.7.0

[1]:
[https://github.com/facebook/relay/pull/2293](https://github.com/facebook/relay/pull/2293)

[2]: [https://github.com/relay-tools/relay-compiler-language-
types...](https://github.com/relay-tools/relay-compiler-language-typescript)

------
Rapzid
For anyone working on Nodejs targeted TypeScript I would highly recommend
checking out ts-node. I use it a ton when I want to not worry about the pre-
compilation step for various reasons. Can work with absolute imports, and
caches code on the first run as well. Pretty sweet.

[https://github.com/TypeStrong/ts-node](https://github.com/TypeStrong/ts-node)

Article mentions ts-jest; can also recommend. I use Jest for all my TS
projects from serverless to selenium. Its watch mode is fantastic.

I also typically use ts-loader with Webpack instead of Babel.

Eh, might as well toss a few more recommendations in there:

* source-map-support

* Bluebird for long stack traces with async/await(v8 now has a zero-cost feature behind a flag now though as of end of 2018)

* Get the debugger hooked up to your browser/nodejs process for a great debug experience

~~~
h1d
Note for --transpileOnly flag which speeds up compilation if you've already
checked for typing errors in your editors and don't need to do it again on
compilation.

There's also ts-node-dev which is a variation of node-dev that auto reloads
files loaded on change.

As for a bundler, parcel supports TypeScript out of the box which just allows
you to write browser side code with TS without effort.

------
drew-y
> This number scared us (a lot) at first but we quickly figured out that most
> of these were related to TypeScript not supporting .js files.

Typescript actually does support .js files. You just need to use the
`--alowJs` option.

~~~
ng12
I think it's a catastrophically poor decision to not have the allowJs behavior
as the default. That one flag fixed almost all of the QOL issues I was having.

~~~
WorldMaker
It's the default if you name your project-level config file jsconfig.json
instead of tsconfig.json, which is an interesting convention versus
configuration trade-off. VSCode makes this somewhat clear in some of its tools
(it will offer to create a jsconfig or tsconfig for you and tries to guess
based on source code metrics), but it's easy to miss in most Typescript
documentation.

------
emilsedgh
What are the chances of ecmpascript adopting optional typing like they adopted
the features in coffescript?

I've seen a few proposals around but it seemed that they were are stalled.

~~~
WorldMaker
TC39 still has scars from ES4 which tried to add optional typing (and is the
only "lost" ES standard that browsers never implemented).

My hope is that since then we have examples like Python's PEP 3107 [0] that
help make sense as where a TC39 proposal could move forward: encourage
browsers to AST parse type annotations, and ignore them by default; leaving
the actual semantics still to tools like Flow and Typescript until there is a
better convergence in semantics and/or browsers have greater needs of specific
type annotations.

[0]
[https://www.python.org/dev/peps/pep-3107/](https://www.python.org/dev/peps/pep-3107/)

------
chris_engel
Lots of love here for TS. I'd like to share my personal experience with it: I
went from "fast and convenient" with JS to constantly fighting against the TS
compiler and linter above cryptic type errors. Man, was it frustrating and JS
felt suddenly crippled because it was hard to use its dynamics. TS catched a
mistake here and there - true - but that did not equal out the hours burned by
writing and debbugging type structures. In the end I removed every bit of TS
from my projects and continued happily without it. I found out that using
JSdoc comments and relying on the linting abilities of my IDE plus writing
unit tests gave me stable code as well, without pulling my hair out. I was
there before TS and just went back to it.

I get that TS may be a good idea if you deal with teams of mediocre devs to
prevent they do stupid things but by talking with a couple of JS devs and
looking at my own JS experience it seems like the desire of using TS vanishes
if you reach a certain experience ans confidence using vanilla JS. It looks
like the most people who embrace TS see JS as some kind of inferior thing,
anyways - but that might just be a wrong observation by me.

~~~
wwwigham
> I went from "fast and convenient" with JS to constantly fighting against the
> TS compiler and linter above cryptic type errors

Would you, perchance, be able to share an example of such an error? We
generally strive to improve error clarity where possible~

> I found out that using JSdoc comments and relying on the linting abilities
> of my IDE

Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually
still getting typechecked by TypeScript ;)

~~~
z3t4
Do you have a list of common errors that TypeScript usually will detect ?

------
ajross
> A very common function in our source code is the invariant function. I can't
> explain it any better than the documentation does

Seems like you'd have an easier time explaining what it does if you'd just
called it "assert()" in the first place. This isn't a new concept, why does it
have a new name?

~~~
zamalek
It originates from design by contract (but is still the incorrect term). An
assertion is not a contract.

~~~
beatgammit
How so? The major design by contract language I know of is D, and its
contracts are essentially asserts that are either placed at the beginning of
the body or prior to all returns.

You can certainly get substantially similar behavior just using asserts at the
beginning of the function body and ensuring asserts at the end before a return
are hit by all code paths (e.g. make an anonymous function that contains the
body, then call it wrapped in a try/catch and assert on the return value.

Unless I'm missing something about design by contract, it's essentially just
asserts at the beginning and end of a function.

~~~
zamalek
Precondition (called invariant here): a set of conditions that must be met in
order to call a method. Another name for argument validation, but it can be
other things (e.g. connected must be true before calling methods on a
connection).

Postcondition: guarantees that a method makes. For instance, it won't return
null.

Invariants (incorrectly used): conditions that always hold true on a type,
e.g. the starting index on a slice must always be greater or equal to zero.

[https://en.m.wikipedia.org/wiki/Design_by_contract](https://en.m.wikipedia.org/wiki/Design_by_contract)

I guess D is guessing via implications, but from what you've said it can't
support invariants, meaning it doesn't strictly qualify as DbC.

------
2T1Qka0rEiPr
No experience of Flow, and I hear all of the opponents of these "superset
JavaScript" solutions who lament their inability to really tighten up the
language in a way that a true static language would. However, JavaScript is
clearly going nowhere anytime soon, and whilst WASM has the ability to change
the state of play, I've found adopting TypeScript in general to be hugely
beneficial.

It's 100% fair to point to all of the things it _doesn 't_ provide, or indeed
the way that it tries to make JS out to be some classical OOP language which
it's not, but it's helped me track bugs and refactor code in ways which would
never have been possible without it, and for that I'm grateful. In comparison
to other tools such as mypy, TypeScript is light-years ahead in its general
ease of use and community support.

------
burtonator
I migrated Polar from JS to Typescript:

[https://getpolarized.io/](https://getpolarized.io/)

It's a pretty sizable app. The migration wet pretty smooth and I would
absolutely never go back. Typescript is amazing.

~~~
lf-non
Polar looks brilliant. Thanks for creating this and making this open source.

------
jillesvangurp
Partially inspired by this post (I was already convinced), I finally finished
adding typescript to a javascript project I recently inherited. I'm an
experienced backend developer but relatively new to frontend javascript stuff.
Short term, I need to own this until we can expand our team.

Errors that a compiler would normally save me from when doing Java/Kotlin are
a major PITA when you are dealing with a foreign code base in Javascript. Over
the past few weeks I've slowly gotten comfortable with the code base, the
build system (rollup, babel, less, and a few other things etc.), and the
frameworks we use (redom, mainly). After updating everything to their latest
versions (e.g. babel 6 -> babel 7) and getting that working; I figured adding
typescript should be straightforward.

Turns out this is super easy and delivers instant value. The hardest part was
figuring out what part of our somewhat convoluted build.js script to modify so
that it processes ts files as well. After finding the relevant for loop and
adding the rollup plugin for typescript that seemed to be working out of the
box. I added a tsconfig.json file to support some ecmascript2017 stuff we
apparently are using.

After that it got easier. I fixed a few hundred lines of javascript code to
have types. That's in my first hour of using typescript. VS Code and tslint
are very helpful. I also found and fixed the first type bug that slipped
through earlier: instant value.

Kudos to MS. Vs Studio Code is a game changer. I've been shying away from
doingb frontend stuff for years for reasons of it seeming to be backwards to
be coding blindfolded with your hands behind your back. VS Studio Code changes
that. Autocomplete, quick fixes, refactorings, import organizing, etc. So much
better than my browser telling me I messed up by not loading the page.

I renamed several js files. Worked my way through the clearly marked warnings.
Mostly quick fix works reasonably well. You do need to replace the any type
with something more appropriate usually (like e.g. string). Anyway, free of
warnings and vs studio code also found and added a redom type definition for
us. Awesome. Very impressed with how easy that went.

Typescript only for me going forward. Opting out of a perfectly good type
system seems silly.

------
hitekker
Glad to hear Typescript is winning hearts and minds. They’ve been great
maintainers; avoiding the infighting, toxicity, and the perverse incentives
that unfortunately plague the front-end landscape.

------
kyranjamie
> We didn't have to buy into an entirely new ecosystem of JavaScript
> development. Dropping Babel for tsc (TypeScript compiler) was scary because
> it wouldn't give us the flexibility

This shouldn't really have been an issue. It's always possible to not do any
transpilation and leave it to another tool

------
fbn79
Ok, well done! BUT.... Now port it to something you can really trust like
Reason ML. See [https://www.reaktor.com/blog/fear-trust-and-
javascript/](https://www.reaktor.com/blog/fear-trust-and-javascript/)

~~~
islon
Or Purescript =)

------
chrisan
Any opinions on Webstorm vs Visual Studio for using TypeScript?

~~~
alexishere1234
I was a long time Webstorm user until switching to Typescript, and found that
its Typescript support is pretty far behind VSCode's. Its been around 6 months
since I switched so I can't remember the specifics, except that VSCode
generally had better indicators of what was wrong with the type.

Neither is perfect at displaying errors but that might also have something to
do with your ts config. I also think that Webstorm is a much better editor
than VSCode in every other respect, but for me VSCode is 1% better for my
productivity so I am forced to use it.

~~~
smt88
> _found that its Typescript support is pretty far behind VSCode_

This isn't (can't be?) true. Both editors use the same language server. I've
used both and found their language support to be identical, and WebStorm feels
a little more natural to me when using automated refactoring.

I also have both eslint and tslint set up through WebStorm, so I have
everything integrated in one place: hinting, linting, compiler warnings, and
compiler errors.

VS Code can do the same, as far as I know. I just prefer WebStorm for other
reasons.

------
Zooper
What is Typescript providing that you don't get by writing 1 test that checks
type and by following modern ECMAScript specs? Does that justify a new syntax?
The answer I think is no. I see much praise in this thread, but very little
definition of why that praise is merited.

~~~
manigandham
Tests don't cover everything and just on input and result. All the code in the
middle can still have bugs that are uncaught because you don't have the right
test for it.

Type systems provide a lot of safety with less work, meaning less bugs and
more productivity. Just having the definitions available when writing makes
you go faster.

~~~
speedplane
> Type systems provide a lot of safety with less work, meaning less bugs and
> more productivity

I hear this argument all the time. As well as the opposite: type systems slow
you down and only catch easy-to-find bugs. Would love to see a real study that
quantifies productivity among static and dynamic systems and ends this flame-
war once and for all.

~~~
manigandham
I dont think there are formal studies but there are quite a few discussions,
this one on SE is good:
[https://softwareengineering.stackexchange.com/questions/5960...](https://softwareengineering.stackexchange.com/questions/59606/is-
static-typing-worth-the-trade-offs)

