There are cultural mishaps and breakages here that are unfortunate to say the least. But the more interesting issues here are assumptions and claims around code quality and static typing (nitpick: TS is statically but also weakly typed). I found this fairly recent paper here and the results are quite sobering. What is certain is that big claims around code quality cannot be verified so far. https://arxiv.org/pdf/2203.11115v1.pdf To add from my perspective: The single most important benefit for static typing is to get computational runtime guarantees: memory footprint, performance etc. TS doesn't provide any of that. (Clojure does to some extent) Secondarily, there's documentation. Manifest typing on function signatures is helpful documentation and can help our editors/IDEs. That can be solved without static typing though. I like static typing when I need it and when it gets me tangible benefits that affect the (compiled) program. Otherwise it seems to me that we're talking about personal preference ("DX" etc.).

From the conclusion of above paper: `Statistical analysis revealed that TypeScript applications show significantly better code quality and understandability than JavaScript applications.`

> Since TypeScript (TS) is assumed to provide benefits for software quality in comparison to JavaScript (JS), yet there is insufficient empirical evidence for this claim

> Surprisingly, however, bug proneness and bug resolution time were both lower for JavaScript projects, thereby defying the assumed benefits of static typing in this area.

@U01EFUL1A8M Not sure your point about weak typing counts as a nitpick. It’s a pretty fundamental design decision for any language.

To be fair, the design decision of TS is not "weak typing is nice". They deliberately wanted to be as close to JS as possible, so TS can be seamlessly and gradually adopted in a JS codebase. The implication of that is weak typing and unsoundness.

Honestly, my experience with Typescript projects is not good - and I know this is not a good measure (personal experience) but usually, I see Typescript code being less straightforward - and I know it's possible to avoid this complexity, but that's not what I see in the wild. Especially now that I'm deeply involved on the Pulsar project (the Atom fork), it's honestly not that hard to understand the JS code they made, even considering all the trade-offs they had to do; now, when I tried to even read the VSCode repository to contribute to a missing feature on Eclipse Theia... I simply could not do it... it's a fractal of all possible "design patterns" mixed between logic and types...

And most Typescript projects I was involved somehow had the same structure (something that in JS was going to be just a function that created an object, in TS became a repository of factories of whatever else...)

TypeScript is uncanny. Not really tangible but still somehow you can do all sorts of type magic with them. Just give me values and let me program with them!

Not sure DHH did that whole reflection and reading of papers before deciding to remove TS. There is a lesson in project stewardship in here but I fail to see it. Once code is in open sourced, does it mean that belongs to the users as much as the founder? Is it really up to the founders to just flip a switch in couple of hours and break contributions suddenly?

I liked the little aphorism in there: > Things that should be easy become hard, and things that are hard become any.

I fully agree with you Sergio! I think it's very bad form to just break so much code and assumptions around it in what seems to be a guerilla PR. I don't think it's even worth discussing further. Perhaps the lesson is that users and participants (not authors/stewards) should be very wary if there is a lack of commitment to stability.

Does it necessarily break code to drop typescript, though?

Interestingly, it does not break users, it breaks contributors who are mid contribution. But so does a big refactor in a project anyway :man-shrugging:

> Surprisingly, however, bug proneness and bug resolution time were both lower for JavaScript projects, thereby defying the assumed benefits of static typing in this area. Within our TypeScript sample, insisting on type safety by refraining from extensively using the any type showed significant, albeit small correlations with better software quality, except for, again, bug proneness talk about mental gymnastics, wtf does code quality mean if it’s orthogonal to bug proneness? wtf does code understandability mean if it’s orthogonal to time to fix bugs after detection? yet another paper where the authors’ priors are simply restated as the conclusions, despite their evidence telling them the exact opposite.

They measured multiple dimensions from what I've gathered. But yeah. Bug proneness and time to fix seem quite important :)

Yea that is what I was thinking too. Their findings should make them question the quality metrics.

In any case. We don't necessarily need to dig up every nuance of every such paper. Als we don't have to worry about missing the train on this: If there were actually meaningful and generally applicable findings on this matter we would hear about it all the time.

facebook -> php twitter -> ruby gh -> ruby uber -> node.js pre-ts, python nubank -> clojure whatsapp -> erlang instagram -> python airbnb > ruby + php udacity -> python + vanilla js lyft -> python + vanilla js I think spotify started html + js, php, flash — w/a few things re: streaming in heavily optimized c++… how many notable cases are there of companies using static langs primarily across the stack that have done the initial zero to one of product launch from bootstrap or seed to take over big market share in a winner-takes-all b2c category in the last couple decades? w/o just pointing at swift, java & kotlin, etc. for native client apps.

thinking of areas where the market is a pretty harsh filter

Not sure that makes sense, I remember a talk about "when web companies grow they turn into java shops" and there are interesting points in there that would contradict the listing above

tbh I’ve always thought that talk was pretty silly. only a handful of examples in it that people would say “that’s a java shop” vs. “one team there happens to be a java shop.” and if you look at the rest of the stack, a better description of the pattern is “when web companies grow they start hitting the limits of single-threaded, interpreted languages”

> how many notable cases are there of companies using static langs primarily across the stack that have done the initial zero to one of product launch from bootstrap or seed to take over big market share in a winner-takes-all b2c category in the last couple decades? That is a great question.

I would also find silly information that contradicts my beliefs 🙂

I can only think of StackOverflow which is C#

BUT to play devil’s advocate, I was also working on a stronger argument for static typing in spite of the article’s self-defeating finding that there are more bugs, just out of the principle of intellectual charity. And I think the boring, middle-of-the-road opinion answer is: static types are more helpful the more devs there are on the project. And projects w/more devs tend to have more bugs and a slower time to bug correction. So there’s possibly a category bias you’d have to control for.

I think we also need to bear in mind that DHH is prone to 🔥 hot takes and seems to like controversy 🙂 At work, the front end team has looked at TS a couple of times and decided that, for them, it just doesn't provide enough benefit to be worth adding to the toolchain. And now that I'm also working on the frontend codebase (any time I run out of backend work to do), I have to say that their JS code is pretty nice to work with, and fairly functional in a lot of ways (React.js, Redux, Immutable.js, lodash) -- and very heavily TDD -- and I don't think I'd enjoy working on it as much if it were TS.

Many, many years ago, I worked at a company that focused on "software QA" by providing code audits, static code analysis tools, and writing coding guidelines. An extensive study out of Europe showed statistically significant benefits to static analysis -- not static typing -- and that was what we leveraged for FORTRAN, C, and C++ code analysis (and, later, Java). I think "static analysis" has gotten even smarter since then and now we have a lot of really good feedback in our editors for dynamically typed languages, via tooling that does type inference and data flow analysis and so on. clojure-lsp and clj-kondo is a great example of that -- given just how dynamic Clojure can be and how hard it is to apply something like Typed Clojure.

💯 on decoupling static analysis from the presence of compiler-required static types.

Maybe too much of an ask, @U04V70XH6 but do you have any references for that study you mention about static analysis?

Unfortunately, no. I really wish I could find the paper again... I've wanted to refer to it several times over the years. I worked at that company in the early '90s...

Evergreen: • https://danluu.com/empirical-pl/ • https://increment.com/teams/the-epistemology-of-software-quality/

dhh is selfish and antisocial, as always. the brash rebel things works a whole lot better when you're not sitting on top of a pile of money while running your own little empire