Insights from Adopting TypeScript at Scale • Hacker News Board

Re: Insights from Adopting TypeScript at Scale

#91

Post by addicted » Thu, Nov 12, 2020, 5:43 PM UTC

didibus wrote: post #68

> Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript, with client-side JavaScript arriving around 2012 Okay, I need another article about why in 2005 they chose to rewrite everything to server side JavaScript? That seems like, I don't want to say a bad decision that also led to all the issues and effort this article describes, but it kinda seems like it. In any cas…

I’d say you’re very wrong. Having worked there the JS ecosystem was a tremendous advantage.

It’s also important to keep in mind that Bloomberg is very willing to have their best developers go ahead and build actual tooling at the compilers (and language) levels to resolve issues they may face.

This occasionally leads to issues when they start diverging from the mainstream too much, but they’re also good about then stepping in and pivoting back to the mainstream development branches, which is kind of what’s happening in this article.

Re: Insights from Adopting TypeScript at Scale

#92

Post by addicted » Thu, Nov 12, 2020, 5:48 PM UTC

dboreham wrote: post #30

darksaints wrote: post #3

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

Fashion.

You’re telling a team that’s contributed significant amounts of code to C++ and are major contributors to setting the standards for C++ that they moved to JS in 2005 (!) for fashion. Ok.

Re: Insights from Adopting TypeScript at Scale

#93

Post by didibus » Thu, Nov 12, 2020, 6:10 PM UTC

addicted wrote: post #91

didibus wrote: post #68

> Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript, with client-side JavaScript arriving around 2012 Okay, I need another article about why in 2005 they chose to rewrite everything to server side JavaScript? That seems like, I don't want to say a bad decision that also led to all the issues and effort this article describes, but it kinda seems like it. In any cas…

I’d say you’re very wrong. Having worked there the JS ecosystem was a tremendous advantage. It’s also important to keep in mind that Bloomberg is very willing to have their best developers go ahead and build actual tooling at the compilers (and language) levels to resolve issues they may face. This occasionally leads to issues when they start diverging from the mainstream too much, but they’re also good about then st…

Sorry, I didn't mean to criticize, more so, I find that choice (in 2005) very surprising. So I'm just curious why would it have been made and how that played out.

> Having worked there the JS ecosystem was a tremendous advantage

How so? And to maybe ground my question, in 2005 I'd have expected a switch to Java, C# or Scala. So what advantages were there compared to those for JavaScript?

> It’s also important to keep in mind that Bloomberg is very willing to have their best developers go ahead and build actual tooling at the compilers (and language) levels to resolve issues they may face

That's awesome, but from my read of the article, seems like a lot of fighting to rebuild things that Java just has. And now this whole move to TypeScript to backfill in types, again, it appears to me like maybe if they'd gone with Java, much less time would have been needed on the devs building their own tooling, compilers and doing massive project migrations.

Re: Insights from Adopting TypeScript at Scale

#94

Post by WorldMaker » Thu, Nov 12, 2020, 6:19 PM UTC

robpalmer wrote: post #17

mirekrusin wrote: post #14

"9. Generated declarations can inline types from dependencies" Why do they generate .d.ts files instead of publishing .ts files alongside .js files? This should solve inlining issue, no?

That's an excellent suggestion! It's true you could just have every package publish the raw TypeScript source-code. So that when an app imports a library, it type-checks against the original source code of the library. No need for DTS files from your dependencies! I have never seen this done in practice for a large system. It's not as scalable as using bare-minimum type declarations that you find in DTS files. It req…

Given Bloomberg already moved most of their infrastructure to TS projects and incremental compiles already, so performance might not even matter or change substantially if they moved to TS only builds so long as they preserved project boundaries. Under the hood the TS compiler in incremental multi-project builds still essentially builds the equivalent of minimal DTS information for projects, but it caches it in a build file that's more compiler-internal oriented than the externally shareable DTS.

A developer with clean/fresh clones would still notice a big performance difference, but amortized over a number of builds it might not matter in general practice. In theory at least, as Bloomberg notes projects and incremental builds are still newish and don't yet always have the performance characteristics they should have in the wild. That said, the impression is that a lot driving projects/incremental compiles is monorepos in Microsoft (at the very least) that have moved to/are moving to monorepos that are entirely TS only builds with few/no DTS intermediaries. (That's just me reading between the lines, of course, I could be mistaken.) The drive behind projects/incremental compiles sounds like it is attempts at massive scales of TS files.

Re: Insights from Adopting TypeScript at Scale

#95

Post by WorldMaker » Thu, Nov 12, 2020, 6:24 PM UTC

a_humean wrote: post #71

horsawlarway wrote: post #19

Earlier quoted context omitted.

I agree on ignoring libraries without definitions. Having to write the definitions myself usually isn't a huge pain, but it's a big red flag showing that it's probably abandoned, and there's no community support around it anymore (or possibly ever).

Yep, these days its basically a proxy for the kinds of smells you look out for when picking a library.

In those cases I will sometimes try to post an offer to write their definitions (or the build step to generate definitions from slightly modified existing JSDoc comments in even more rare cases) and PR them to the project if they like. How a project responds (or doesn't) to that Issue often tells you so much about current maintenance habits.

Re: Insights from Adopting TypeScript at Scale

#96

Post by WorldMaker » Thu, Nov 12, 2020, 6:38 PM UTC

robpalmer wrote: post #34

lemming wrote: post #32

Earlier quoted context omitted.

Do the breaks tend to affect the TS declaration files, or are they more to the language itself?

The majority of breaks are due to the checker getting better. So code that passed now errors. Most of the time pre-existing published DTS files still operate fine.

Yeah, in most cases the breaks are because of how DTS files are interpreted in consuming projects, as new strictness checks light up. Most of the time that has seemed to be what the DTS files really intended and the previous interpretation less useful.

A useful example is Strict Null Checks which started to treat unadorned types as non-nullable (string versus string? versus string | null). In most cases the runtime behavior of libraries were already throwing errors when nulls were passed in, and the extra checks helped immensely. In rarer cases "oh yeah, null is totally a valid thing to send to this API and it has some defined behavior that we document/should document" and the DTS files were encouraged to annotate their types to include that. In the worst where libraries had such APIs but failed to update their DTS files, there were explicit casting workarounds in consuming projects (the awkward `null as string` and the so called "damn it" operator `possiblyNullString!`).

Re: Insights from Adopting TypeScript at Scale

#97

Post by didibus » Thu, Nov 12, 2020, 6:45 PM UTC

robpalmer wrote: post #73

didibus wrote: post #68

> Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript, with client-side JavaScript arriving around 2012 Okay, I need another article about why in 2005 they chose to rewrite everything to server side JavaScript? That seems like, I don't want to say a bad decision that also led to all the issues and effort this article describes, but it kinda seems like it. In any cas…

Yes, you're right the JS@Bloomberg origin story deserves to be told in full. Probably by Andrew Paprocki. SpiderMonkey has a starring role. Until then this is as much as I can share right now: https://news.ycombinator.com/item?id=25068119 Also to be clear, we don't have a language monoculture. The app layer and hundreds of services use JS/TS. But the majority of the backend remains C++.

That's an interesting take. I'm now a Clojure programmer, so I totally understand the importance of a tight feedback loop. I guess in 2005 Lisp would have still been considered too "different" even though it had a longer history of backend development compared to JavaScript and an even tighter loop?

I'd be very interested in an origin story. The emphasis on tight feedback loop is very novel for the time I feel, over going with Java for example, which could have been a middleground between feedback loop and type safety with much more tooling available at the time. And now with bringing types back in, slowing down the build times again, hurting the feedback loop, but it seems safety has now been favored over it, was it a change of heart, what lead to that?

Anyways I'll patiently await a maybe blog post about it :)

Thanks for the right up here, was very fascinating.

Re: Insights from Adopting TypeScript at Scale

#98

Post by evmar » Thu, Nov 12, 2020, 7:30 PM UTC

mirekrusin wrote: post #59

evmar wrote: post #51

Earlier quoted context omitted.

Another consideration is that it only works if all the code agrees on tsconfig settings (e.g. strictness settings and path resolution). That can work in a monorepo but won't work if you mix libraries.

Yes, they mention taking over tsconfig management because even generated .d.ts files are sensitive to tsconfig - article mentions type being different depending on the tsconfig setting. But in general publishing the most strict ts should work fine when using from weaker tsconfig. Personally I don't use custom path resolutions, can't comment on that. ps. oh wait, but why does it matter? .d.ts file won't be different i…

Suppose project B uses lax tsconfig settings. Now suppose strict project A imports from B. If A uses B via d.ts it may be ignorant of most of B's choices. But if A uses B as source, A's strictness settings will now attempt to apply to B.

Re: Insights from Adopting TypeScript at Scale

#99

Post by jariel » Thu, Nov 12, 2020, 10:25 PM UTC

robpalmer wrote: post #78

jariel wrote: post #53

It seems what they really want is something that is not javascript. The TS team was adamant they wanted to not be a runtime, i.e. it was JS + Typing only. Partly I wish they just dumped ECMA and just made TS proper, but perhaps that's just Dart.

I can empathize with this view. JavaScript is bound by backwards compatibility. It is expressed by the soundbite "don't break the web" . I would love for typeof null to not be "object" , and it seems appealing to say "well if JS won't fix it, maybe TS should." The problem is that this outcome has many negative effects including loss of trust. Orta (a member of the TypeScript team) describes this exact scenario in his…

Yes, the market dictated that move, a non-TS JS may have fallen flat.

That said, it's MS, not some side project. They could feasibly take the road to 'pure TS' especially now that they have the core following and MS has some brand trust.

There's probably a huge following of folks that would jump on a Pure TS train as long as it wasn't cloistered by all the .Net legacy.

Like PureTS on Mono VM type thing.

Re: Insights from Adopting TypeScript at Scale

#100

Post by hvidgaard » Fri, Nov 13, 2020, 8:32 AM UTC

robpalmer wrote: post #84

hvidgaard wrote: post #80

Earlier quoted context omitted.

That is very true. But I still have a hard time to see the justifications of using JS on the server.

I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions. Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switc…

I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.