Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Insights from Adopting TypeScript at Scale

techatbloomberg.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#71

Post by a_humean »

horsawlarway wrote: post #19
a_humean wrote: post #15

Earlier quoted context omitted.

Its actually quite rare to see a library without either first or third party support these days. Many new libraries are either written in typescript, or the authors have taken care to create declaration files or contribute to definately-typed. If a library reaches any degree of popularity it usually isn't long before a third party declaration appears. Older libraries that are long abandoned by their maintainers usual…

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.

Re: Insights from Adopting TypeScript at Scale

#72

Post by cryptica »

nicoburns wrote: post #26
Roboprog wrote: post #20

Earlier quoted context omitted.

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

Have you used TS much? In my experience idiomatic TS isn't much different to idiomatic JS and a far cry from Java style OOP code (the Angular ecosystem which was admitedly an early adopter of TS is an exception and best avoided).

I used TS for several years and also don't like it. Nothing wrong with the language itself but the transpilation step adds significant complexity and is very slow so it breaks my train of thought and slows down my development iteration speed significantly. In addition to slow iteration speed, I got tired of encountering source mapping issues in some environments, version compatibility issues and TS config issues (especially when config property names change with the versions).

Also, static typing adds no value at all to programming if your project code is well structured. It's only useful for spaghetti code monoliths. If you make your code modular with good tests, you won't need type safety because your modules will be simple enough that your tests will easily catch these errors.

My view is that TypeScript encourages developers to write overly complex spaghetti code because it encourages devs to pass around active object references instead of simple primitives like strings, numbers or other primitive data types.

Alan Kay, one of the founders of OOP himself said that the point of OOP is not objects, "The big idea is messaging". Passing around complex typed instances goes completely against that. An instance is not a message. Complex instances (which have their own state and methods) are not messages; they should generally not be used for messaging between different components (I.e. as arguments or return values).

Re: Insights from Adopting TypeScript at Scale

#73

Post by robpalmer »

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++.

Re: Insights from Adopting TypeScript at Scale

#74

Post by cryptica »

coding123 wrote: post #5

I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…

Corporations seem to be desperately trying to create more jobs at the moment. TypeScript, by being less efficient and adding complexity, allows massive job creation to take place.

Nothing to do with bugs, efficiency, etc... It's all about job creation so that companies can justify receiving more, bigger government contracts and loans on favorable terms from banks and they get more political influence by coercing their employees into voting for specific candidates (more headcount = more voting power).

Re: Insights from Adopting TypeScript at Scale

#75

Post by tchetwin »

woile wrote: post #69

> undesirable features by preventing their use. I wonder if they have published those rules, I'd like to see them as I'm just diving into TS.

These rules are currently a not-readily-separable part of our build tooling. To provide earlier feedback for developers we're intending to standardise on an ESLint ruleset that will probably comprise the `no-restricted-syntax` rule: https://eslint.org/docs/rules/no-restricted-syntax

Re: Insights from Adopting TypeScript at Scale

#76

Post by robpalmer »

hvidgaard wrote: post #61
JonathonW wrote: post #7

Earlier quoted context omitted.

I think the key here is: > Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript Since their use of Javascript predates Node (and the rest of that ecosystem, like Webpack or Babel or whatever), they've built up their own Javascript environment that doesn't rely on Node or Node conventions at all. Not so much a "get around odd shitshows" situation as much as a parallel…

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

Re: Insights from Adopting TypeScript at Scale

#77

Post by robpalmer »

no_wizard wrote: post #55

I envy this. If you guys are ever hiring, I'd do anything to be apart of such an innovative place! This is the kind of work that gets me excited to live every day. This really shows though, to the point of the article, that TypeScript at scale really lives up to its name, albeit with some quarks (and in this case, some of those quarks are also due to the environment it operates in). I have also found over the years m…

Thanks for the feedback - I'm pleased you enjoyed it.

It's true the codebase has some gnarly advanced types (generic, conditional, mapped) for expressing types for constructs created prior to TypeScript being introduced. I suspect we are pushing the limits of the compiler - quite literally TypeScript has fixed limits on recursion depth that have caused us breaks in the past. Hopefully as we refactor code with TypeScript in mind we can reduce the overall type complexity.

And only because you asked... if you wish to join us, please check out https://careers.bloomberg.com

Re: Insights from Adopting TypeScript at Scale

#78

Post by robpalmer »

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 video "How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem" in which he talks about TypeScript "Embracing and Extending" JavaScript: https://www.youtube.com/watch?v=qr0TnQ2mHwY

The TS team seem to be firmly going in the direction of ECMAScript alignment and the JS + Types model, which is something the article advocates for too. Overall this increases my trust in the technology.

On a related topic Bjarne Stroustrup once said "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Re: Insights from Adopting TypeScript at Scale

#79

Post by robpalmer »

cryptica wrote: post #70
Roboprog wrote: post #20

Earlier quoted context omitted.

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

What I've found is that senior developers with 10+ years of experience with many different paradigms and projects tend to enjoy JavaScript and many hate TypeScript (particularly because of the build step and complexity that it brings). But for some reason Microsoft is running a lot of propaganda campaigns to promote TypeScript. My guess is that they're trying to push all the JS devs to TS and then once they have enou…

The scenario you are describing (TypeScript diverging from JavaScript) is unlikely in my opinion.

Orta, a member of the TypeScript team, describes the reasons why in his video "How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem" https://www.youtube.com/watch?v=qr0TnQ2mHwY

It directly answers the question of "What would a malicious version of TypeScript look like" and explains why this is unlikely to occur.

Re: Insights from Adopting TypeScript at Scale

#80

Post by hvidgaard »

robpalmer wrote: post #76
hvidgaard wrote: post #61

Earlier quoted context omitted.

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point. My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

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