Google Feedback on TypeScript 3.5 • Hacker News Board

Re: Google Feedback on TypeScript 3.5

#101

Post by dmix » Mon, Sep 09, 2019, 6:48 PM UTC

gmoot wrote: post #99

dmix wrote: post #83

> but any time someone saves a Selection into a member variable, they ended up writing down whatever type TS inferred at that time, e.g. > mySel: d3.Selection ; I'm curious how Google and others approach adopting Typescript gradually, as I'm pretty new to it, I'm assuming it goes like: The programmer converts code to Typescript and when they come across return types they copy the inferred type and add it to the codeb…

The explicit type is optional. It's not that it's required to copy out whatever the compiler inferred, it's just that lots of people do it to be explicit.

All types are optional in typescript. I was just curious about Google's approach to it and if they had some standard practice of always copying the inferred type to get a great amount of coverage.

Re: Google Feedback on TypeScript 3.5

#102

Post by whatshisface » Mon, Sep 09, 2019, 7:20 PM UTC

evmar wrote: post #78

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…

Thanks for highlighting this bit, I also find it very interesting to think about! Here's a related property I've also discovered of 'advanced' type systems. In my understanding of how unification happens in systems like H-M, you first give every expression its own type variable, then perform a search to produce assignments to those that remain valid and leave the remainders generic. But as your type system gets fanci…

That problem has a simple solution: you, the programmer, should write type signatures in appropriate places as a combination of what documentation and assert statements do in other languages. No compiler today could be reasonably expected to guess which inferences the human brain will find surprising, which is why it's up to the programmer.

Re: Google Feedback on TypeScript 3.5

#103

Post by softawre » Mon, Sep 09, 2019, 7:47 PM UTC

cptwunderlich wrote: post #23

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…

I have no personal experience with this, but can't Kotlin target the JVM, native and JavaScript?

Yeah. We've tried this, also sharing typescript code, but we've decided that sharing the same business logic code everywhere just isn't worth all the extra work to do so.

Re: Google Feedback on TypeScript 3.5

#104

Post by umvi » Mon, Sep 09, 2019, 7:48 PM UTC

burtonator wrote: post #61

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…

To be clear, are you using TypeScript for both frontend and backend?

Are you using Angular as your frontend?

Re: Google Feedback on TypeScript 3.5

#105

Post by papln » Mon, Sep 09, 2019, 7:50 PM UTC

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.

Sure. But if you write some code (or update a dependency) and it breaks with spooky action at a distance, the first thing you should do is to pay off your tech debt and add type signatures to find the breakage, before thinking about changing TS.

The github comment says: " (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.)"

The first part is exactly right; the second part is well established in the Rust language spec and Haskell style guides like http://www.cis.upenn.edu/~cis552/current/styleguide.html and https://kowainik.github.io/posts/2019-02-06-style-guide#func...

Re: Google Feedback on TypeScript 3.5

#106

Post by papln » Mon, Sep 09, 2019, 7:53 PM UTC

blauditore wrote: post #43

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 w…

> But I suppose that's difficult to visualize in a well human-readable way.

It's not. The type-checker must have constructed a call stack of inferred types in order to find the violation, so it simply has to print all the calls (source line and line number) and the types it deduced, and let the programmer (or IDE) compare that to the code in context and look for surprises.

Re: Google Feedback on TypeScript 3.5

#107

Post by umvi » Mon, Sep 09, 2019, 7:53 PM UTC

andreigaspar wrote: post #2

So happy to see the attention Typescript is getting lately. Absolutely love the language, and have been using it since it got released.

I tried using it with Angular, but it doesn't seem to help much. For example, if you have something like:

And then a TypeScript function like:

    login(email: string, pass: string) {
    
    }

TypeScript can't help you at all here because all the typing is determined at runtime by Angular. Even if `email` is a number or a boolean, no problem, it will just happily pass it in.

What benefit, then, does TypeScript provide? I understand it's compile-time guarantees, but how does that help if the types are coming in from HTML land which the TypeScript compiler doesn't examine at all?

Re: Google Feedback on TypeScript 3.5

#108

Post by _the_inflator » Mon, Sep 09, 2019, 8:01 PM UTC

It is very funny to read this from Google, since we talked about similar problems with Google regarding Angular upgrades, where features were modified that Google considered not used/no use cases known, while we were relying on these.

From my point of view Core members of any super large project (like React, Angular, TypeScript) are limited by design in what they perceive as their target audience and their use cases. This is simply a matter of fact: even as a core dev you cannot know how every dev uses your product.

So this is some sort of left-pad moment for TypeScript.

Re: Google Feedback on TypeScript 3.5

#109

Post by bsaul » Mon, Sep 09, 2019, 8:02 PM UTC

wilgertvelinga wrote: post #72

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…

If you do go with TypeScript have a look at Nx. It's tooling around TypeScript monorepo that helps you do exactly what you want: write code once and share it between backend/multiple frontends. It suppports Express or NestJS in the backend and Angular, React, Web Components in the Frontend. https://nx.dev/ If you want to make it work with Ionic/NativeScript/Electron as well use xplat. https://github.com/nstudio/xplat

I don’t see anything regarding mobile platform (native).

Re: Google Feedback on TypeScript 3.5

#110

Post by mumblemumble » Mon, Sep 09, 2019, 8:12 PM UTC

evmar wrote: post #78

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…

Thanks for highlighting this bit, I also find it very interesting to think about! Here's a related property I've also discovered of 'advanced' type systems. In my understanding of how unification happens in systems like H-M, you first give every expression its own type variable, then perform a search to produce assignments to those that remain valid and leave the remainders generic. But as your type system gets fanci…

This seems like a good task for a linter and some commit hooks.

During development, I like to keep my types unspecified until I'm confident that things have congealed properly. But before merging, I like to make sure and add type annotations to anything that's meant for public consumption.

Partially for readability and documentation. Partially because adding those annotations ensures that the type checker and I are on the same page. But mostly because those manual type annotations represent a promise that I, the programmer, have made about the current and future behavior of a certain chunk of code. Once those promises have been codified, then the type checker has my back and can help warn me if I'm about to break one of them with a careless change at some point in the future.