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

Google Feedback on TypeScript 3.5

github.com

Post reply on HN
Print view View original

61–70 of 149 posts

Re: Google Feedback on TypeScript 3.5

#61

Post by burtonator »

Typescript is absolutely amazing. I've been working with it for the last 8 months.

https://getpolarized.io/

and the source is here:

https://github.com/burtonator/polar-bookshelf

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.

Honestly, the MAIN issue with TS are issues around webpack + typings for 3rd party and older modules.

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.

I have 20 years of Java experience. Used it since 1.0 and for the most part have been unhappy with everything else.

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.

Could NOT have made so much progress without TS.

Re: Google Feedback on TypeScript 3.5

#62

Post by kyrra »

psv1 wrote: post #9

Not a TypeScript user, but what really stood out to me is that Google are using a monorepo.

Another interesting bit with the monorepo is the one-version-policy:

https://opensource.google.com/docs/thirdparty/oneversion/

That's why the typescript upgrade was so hard for them. We (attempt) to enforce a single version of a library/toolchain to be checked into the codebase at any given time. You can have multiple in during an upgrade, but it's highly discouraged.

Re: Google Feedback on TypeScript 3.5

#63

Post by jchw »

cypressious wrote: post #50
fluffything wrote: post #38

Earlier quoted context omitted.

IIRC there are a couple of Rust write ups about this. In Rust, inference is limited within functions. The language doesn't allow inferring the argument or return types of functions to avoid this kind of action at a distance. The function API is just one of the many arbitrary places where one can limit inference and require users to provide types. In other languages the module boundary might also be an appropriate pla…

A big part of TS is the ease of transition from JS where you immediately get benefits through gradual typing and return type inference is probably a big part of that.

This is true, but a lot of projects are now starting with TS, and maybe could benefit from intentional limitations on inference, at least locally. I’m pretty sure most folks start new projects with strict enabled as is.

Re: Google Feedback on TypeScript 3.5

#64

Post by vicapow »

lxe wrote: post #51

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

I’m not sure I agree. I’ve found updating Flow in a rather large monorepo a relatively straightforward process. The changes are usually rather small because the team releases every two weeks. They also manage the update internally within their company’s monorepo so they’ll usually find out about these types of unexpected behavior changes before the community does.

That said, we do rely on automated error excludes (similar to eslint-ignore-next-line) for things that cannot be fixed with codemods. Those errors were always there it’s just now you know about them. Better to stem the bleeding by updating the type checker to the latest version.

Re: Google Feedback on TypeScript 3.5

#65

Post by nih0 »

jmillikin wrote: post #21
Dobbs wrote: post #13

Earlier quoted context omitted.

Google is pretty notorious for this. It is one of the reasons behind the old golang GOPATH setup, and one of the reasons it took so long for the Go taking so long to get modules.

I'm not sure that's true. The layout of Go code in Google's monorepo is not at all similar to GOPATH, and patterns that are common within google3 (such as multiple Go packages in one directory) are fundamentally incompatible with the Go build system. As an ex-Googler, I still strongly prefer the google3 style and am annoyed when open-source Go tooling can't deal with it properly.

what is google3 style?

Re: Google Feedback on TypeScript 3.5

#67

Post by lxe »

vicapow wrote: post #64
lxe wrote: post #51

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

I’m not sure I agree. I’ve found updating Flow in a rather large monorepo a relatively straightforward process. The changes are usually rather small because the team releases every two weeks. They also manage the update internally within their company’s monorepo so they’ll usually find out about these types of unexpected behavior changes before the community does. That said, we do rely on automated error excludes (si…

> I’ve found updating Flow in a rather large monorepo a relatively straightforward process.

I'm not sure you're being entirely honest here, as we both know through feedback that flow updates in the said monorepo are one of the most burdensome processes for its contributors.

As a maintainer/owner of a monorepo experience, it's crucial to maintain empathy and honesty of how processes such as dependency and tooling updates affect (and are perceived by) its users.

Re: Google Feedback on TypeScript 3.5

#68

Post by dominotw »

cutler wrote: post #41
slifin wrote: post #25

Earlier quoted context omitted.

Clojure has a specification language that can express more and less things than a type system can and runs on mobile web desktop with flexible choices for run times

Good luck untangling re-native built on re-frame built on Reagent built on shadow-cljs built on React native built on React built on Android/iOS when one of those parts change.

so in that equation applies to all of JS transpilers. Why this a clojurescript specific complaint?

Re: Google Feedback on TypeScript 3.5

#69

Post by vicapow »

lxe wrote: post #67
vicapow wrote: post #64

Earlier quoted context omitted.

I’m not sure I agree. I’ve found updating Flow in a rather large monorepo a relatively straightforward process. The changes are usually rather small because the team releases every two weeks. They also manage the update internally within their company’s monorepo so they’ll usually find out about these types of unexpected behavior changes before the community does. That said, we do rely on automated error excludes (si…

> I’ve found updating Flow in a rather large monorepo a relatively straightforward process. I'm not sure you're being entirely honest here, as we both know through feedback that flow updates in the said monorepo are one of the most burdensome processes for its contributors. As a maintainer/owner of a monorepo experience, it's crucial to maintain empathy and honesty of how processes such as dependency and tooling upda…

Apologies, lxe. I can tell you're frustrated. If the the Flow upgrade process has been burdensome to others, I'd really like to know. I've always thought we've done a good job of updating internally on the platform team and that it hasn't been a concern for end users. We did run into some pain points in changing configuration options around the unnecessary optional-chaining lint rules but that wasn't related to updating the Flow version. I think you may be conflating those.

Re: Google Feedback on TypeScript 3.5

#70

Post by slig »

psv1 wrote: post #9

Not a TypeScript user, but what really stood out to me is that Google are using a monorepo.

How does that work on a nodejs project? I understand that they only have one version of the TypeScript compiler for all projects inside the monorepo, so that means there's only one huge package.json inside with all the packages used by every project inside the repo?
Post reply on HN