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

41–50 of 149 posts

Re: Google Feedback on TypeScript 3.5

#41

Post by cutler »

slifin wrote: post #25
bsaul wrote: post #17

A little off-topic: 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. Does someone knows of another alternative (viable right now, or in the coming months) ? I know llvm can theoretically targe…

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.

Re: Google Feedback on TypeScript 3.5

#43

Post by blauditore »

heavenlyhash wrote: post #14

> (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.) This is a very outstandingly interesting line out the whole writeup. 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 typ…

I think the underlying problem is that in cases of long inference chains, it's hard to detect where the problem lies if types on both ends don't match. In my experience, the compiler will just show an error on the "latter" end, then the user needs to trace inference back and figure out where things went wrong.

Personally, I experience this quite often, e.g. in Java whenever arrow functions are heavily used, such as with streams.

It would be nice to have compilers report the whole inference chain somehow, just to be clear about all possible spots where things might be wrong. But I suppose that's difficult to visualize in a well human-readable way.

Re: Google Feedback on TypeScript 3.5

#44

Post by hollerith »

heavenlyhash wrote: post #14

> (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.) This is a very outstandingly interesting line out the whole writeup. 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 typ…

Just to clarify: you're suggesting I believe that the programmer should be advised by the compiler to add one or two explicit type declarations to certain programs, not that the compiler should refuse to compile any programs that currently compile.

Re: Google Feedback on TypeScript 3.5

#47

Post by yoz-y »

apalmer wrote: post #33
psv1 wrote: post #9

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

that stood out to me too... not the monorepo really, but the fact its a monorepo of a billion lines of code. seems almost impossible to maintain when you have a dependency change at the lowest levels that affects numerous projects.If i am understanding google was in a situation where they had to update every project that used typescript inside the entire company at the same time, that seems untenable.

Mostly it means that you have to be really thoughtful when introducing a breaking change to a low level library.

Re: Google Feedback on TypeScript 3.5

#48

Post by bpicolo »

tannhaeuser wrote: post #4

Is there a way to migrate jsdoc-annotated JavaScript code over to TS, and is TS's minifier as good as Google's closure-compiler yet?

The Angular project has a package for translating TS -> Closure, which appears to be used at Google in some capacity. https://github.com/angular/tsickle

Re: Google Feedback on TypeScript 3.5

#49

Post by _bxg1 »

heavenlyhash wrote: post #14

> (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.) This is a very outstandingly interesting line out the whole writeup. 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 typ…

Typically my strategy is:

1) Make types explicit (or generic) at any interface boundary

2) Periodically query the inferred types of things from my editor just to make sure they come out to what I expect

3) If an error message feels like it's in the wrong place or an inferred type isn't what it should be, progressively make things more explicit until the problem is resolved

But you're right, that's all very subjective and dependent on learned norms.

Re: Google Feedback on TypeScript 3.5

#50

Post by cypressious »

fluffything wrote: post #38
heavenlyhash wrote: post #14

> (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.) This is a very outstandingly interesting line out the whole writeup. 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 typ…

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.
Post reply on HN