> (I might suggest the underlying problem in this code is relying on inference too much, but the threshold for "too much" is difficult to communicate to users.)<p>This is a <i>very</i> outstandingly interesting line out the whole writeup.<p>I like the writeup in its entirety for being very balanced and thoughtful, but this line in particular really stands out to me as worth more thought for anyone interested in language and type system design.<p>Inference is great.<p>Except... when it's not. When it's "too much". When it starts making breaking changes appear "too distantly".<p>It's an interesting topic to reflect upon, because the inference isn't <i>making</i> a breakage; just shifting around where the breakage <i>appears</i>. (And this makes it hard to ever direct criticism at an inference mechanism!) But this kind of shifting-around of the breakage appearance can be a drastic impact on the ergonomics of handling it: how early it's detected, how close to the important change site tooling will be able to point the coder, etc. That's important. And almost everything about it involves the word "too" -- which means the area is incredibly subjective, and requires some kind of norm-building... while not necessarily providing any clear place for that norm-building to center around.<p>I don't have a point here other than to say this is interesting to reflect on. I suspect the last chapter on type inference systems has not yet been written. Can an inference system be designed such that it naturally restrains "too" much use of it?
Typescript is absolutely amazing. I've been working with it for the last 8 months.<p><a href="https://getpolarized.io/" rel="nofollow">https://getpolarized.io/</a><p>and the source is here:<p><a href="https://github.com/burtonator/polar-bookshelf" rel="nofollow">https://github.com/burtonator/polar-bookshelf</a><p>I could have NOT made as much progress just by using JS directly. When you have a large code-base and you're trying to make progress as fast as possible refactoring is needed and the strict typing is invaluable.<p>Honestly, the MAIN issue with TS are issues around webpack + typings for 3rd party and older modules.<p>I'd say 85% of the code I want to use already has types but when they don't it's frustrating to have to pause and write my own types.<p>I have 20 years of Java experience. Used it since 1.0 and for the most part have been unhappy with everything else.<p>I've decided that Node + Typescript is by far the most productive environment for me to switch to. I can code elegant apps with both front and backends and I get strict typing.<p>Could NOT have made so much progress without TS.
This write-up led me to Evan Martins blog. What a gold mine. Digestible writing with a peek inside of Google's internals. <a href="http://neugierig.org/software/blog/" rel="nofollow">http://neugierig.org/software/blog/</a>
I love TypeScript. I started using it around v1.0. Microsoft has hit some gold with it.<p>When I first started using it I had lots of `any` in my code (like the Google employee is describing here). But over time it really starts being extremely clean.
Issues like these are the reason we can thrive as a community. Not playing a blame-game and offering direct feedback to a wonderful open source project. Trying to get my own company to get more involved in feedback to the open source tools we use as I think it is so extremely respectful and encouraging!
A little off-topic:<p>I'm currently trying to find a way to write (type safe) business logic once, then reuse it pretty much everywhere (mobile / web / desktop),and it seems to me that typescript has become the only option. Javascript runtime is present everywhere, and can interface with anything.<p>Does someone knows of another alternative (viable right now, or in the coming months) ? I know llvm can theoretically target any platform, including wasm, but how painfull is it in practice ? Can you write a line of code that does a network request then expect it to run as it is on the browser and on mobile platforms ?
I've recently built a Node server with TypeScript and it's a joy to use with external libraries when the types are available. It's such a time saver to not have to guess which method to call with which arguments (I've had only experience with dynamic languages before). Some libraries don't have types or they are outdated but it was a minority.<p>With the experience I've found that most of the type errors are actually between the backend and the frontend in web applications. It's still hard to fully type the entire flow from the database calls with the ORM to the objects manipulation in the frontend.<p>How are you dealing with that? We used Nexus with GraphQL but it was still a bit cumbersome.
Almost every single Flow version upgrade is like this — every new version brings a slew of errors due to Flow’s continuous movement away from practicality towards “soundness”.
> but any time someone saves a Selection into a member variable, they ended up writing down whatever type TS inferred at that time, e.g.<p>> mySel: d3.Selection<HTMLElement, {}, null, undefined>;<p>I'm curious how Google and others approach adopting Typescript gradually, as I'm pretty new to it, I'm assuming it goes like: The programmer converts code to Typescript and when they come across return types they copy the inferred type and add it to the codebase directly wherever possible. I'm assuming just as a matter of using (untyped) libraries you need to rely on the output of Typescript in order to try have every return typed.<p>So the biggest problem seems to be how TS infers things changed meaning you can't always trust what you copied as staying consistent, even if the source library doesn't change itself. That's always something to keep in mind for overhead.
It is very funny to read this from Google, since we talked about similar problems with Google regarding Angular upgrades, where features were modified that Google considered not used/no use cases known, while we were relying on these.<p>From my point of view Core members of any super large project (like React, Angular, TypeScript) are limited by design in what they perceive as their target audience and their use cases. This is simply a matter of fact: even as a core dev you cannot know how every dev uses your product.<p>So this is some sort of left-pad moment for TypeScript.