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

121–130 of 149 posts

Re: Google Feedback on TypeScript 3.5

#121

Post by charrondev »

umvi wrote: post #104
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?

Not the parent here, but I use TypeScript with React day to day, as well as with node.

I feel a lot less productive without it and the interaction with React has been perfect in my view for the last couple of months.

With hooks allowing a lot more inference in typing and removing most need for Higher Order Components, there aren’t any places where the typing feels like a big impediment. It’s definitely a lot better than it was, say a year ago.

Re: Google Feedback on TypeScript 3.5

#122

Post by lonelappde »

evmar wrote: post #120
whatshisface wrote: post #102

Earlier quoted context omitted.

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.

This is the point under discussion though -- humans think they're reasoning the same way as the inferencer but can't get it right in the limit, so they're not really equipped to know where they ought to have added type annotations. See e.g. the comment here about the inferencer working 'backwards': https://github.com/ReactiveX/rxjs/issues/4959#issuecomment-5... .

You add the types on every function definition, and almost never have a problem.

Many people forget that the point of type inference is to eliminate uselessly redundant clutter, not to completely eliminate types from source code. A function is usually called many times, so keeping types on public API definitions and eliminating types from call sites and throwaway REPL code eliminates a huge amount of wasted typing (hah!) with near no loss of clarity.

Re: Google Feedback on TypeScript 3.5

#123

Post by lonelappde »

_bxg1 wrote: post #49
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…

This is the same strategy I use for writing tests. This is natural, because types are compile-time tests.

Re: Google Feedback on TypeScript 3.5

#124

Post by lonelappde »

_bxg1 wrote: post #96
vicapow wrote: post #92

Earlier quoted context omitted.

How can null be implicitly cast to a string? I wasn't able to reproduce with: https://flow.org/try/#0PTAEAEDMBsHsHcBQiDGsB2BnALqAhgFyg4BOA... Flow has built in support for the Language Server Protocol. tsserver doesn't even support LSP. I agree ts has better IDE support but that's in part because they don't use LSP. odd they expect others to follow it when they don't.

In plain JavaScript, 'foo' + null == 'foonull'. This isn't always what you want, but in the vast majority of cases if you're creating a string, it's: 1) For displaying to the user 2) Generating a CSS class or something to that effect In both of these cases the above is quite a reasonable behavior, and will never cause a runtime exception, and very rarely even a business-logic error. But if I'm working with the result…

Can you define an alternative to '+' that explicitly accepts null?

Re: Google Feedback on TypeScript 3.5

#125

Post by lonelappde »

dmix wrote: post #101
gmoot wrote: post #99

Earlier quoted context omitted.

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.

Copying the inferred type is the same as copying your runtime outputs into your tests. It's a statement that you believe the result is correct and it's on you to make that judgement call. It's not a policy to blindly copy everything, because that defeats the purpose of type checking and testing, turning your tests into " verify that nothing changed", not "verify that the system behaves as intended".

Re: Google Feedback on TypeScript 3.5

#126

Post by gregplaysguitar »

juliendc wrote: post #117

I've recently built a Node server with TypeScript and it's a joy to use with external libraries when the types are available. It's such a time saver to not have to guess which method to call with which arguments (I've had only experience with dynamic languages before). Some libraries don't have types or they are outdated but it was a minority. With the experience I've found that most of the type errors are actually b…

We use https://graphql-code-generator.com/ in combination with some scripts which update the graphql schema at build time - works great. Using Apollo on the front end.

Having types straddle the client/server divide is a huge win

Re: Google Feedback on TypeScript 3.5

#127

Post by rossjudson »

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…

You should have let other people highlight this bit.

Re: Google Feedback on TypeScript 3.5

#128

Post by WorldMaker »

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 also found it interesting because just as the later sections complain about cases where they relied on inferencing "too much", the earliest section also shows cases where they relied on inferencing "not enough". (Had the developer not explicitly typed by copying the inferred type from a tooltip for that D3.js return object, for instance, and left it to be inferred, it wouldn't have been broken in the generics change.)

It's an interesting goldilocks paradox likely only exacerbated by the size of Google's codebase and variety of developer code styles/inferencing preferences.

Re: Google Feedback on TypeScript 3.5

#129

Post by threecreepio »

umvi wrote: post #107
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 unders…

For your template code in angular, there won't be any significant benefit to using typescript. It could be worse than not having typescript at all, since you can add type annotations to your 'login'-function that don't match up with reality.

That's not really a typescript issue though, and it works great with libraries that don't use string templates. From what I've seen the angular community hasn't really prioritized a typecheck-able templating language.

Re: Google Feedback on TypeScript 3.5

#130

Post by WorldMaker »

lonelappde wrote: post #122
evmar wrote: post #120

Earlier quoted context omitted.

This is the point under discussion though -- humans think they're reasoning the same way as the inferencer but can't get it right in the limit, so they're not really equipped to know where they ought to have added type annotations. See e.g. the comment here about the inferencer working 'backwards': https://github.com/ReactiveX/rxjs/issues/4959#issuecomment-5... .

You add the types on every function definition, and almost never have a problem. Many people forget that the point of type inference is to eliminate uselessly redundant clutter, not to completely eliminate types from source code. A function is usually called many times, so keeping types on public API definitions and eliminating types from call sites and throwaway REPL code eliminates a huge amount of wasted typing (h…

In the case of an RxJS pipeline, as one example, you often have a huge variety of lambda functions that may indeed be called many times, but often exist themselves as "one off" pieces in a pipeline. Leaving the types to be inferred and/or generic, is sometimes even necessary for the most code-reuse of functions between pipelines. It's also rare for such functions to feel like they are a part of a public API definition, because they feel so huge a part of internal and boring plumbing.

As someone that has done a lot of RxJS (and kindred libraries) programming over the last few years, I have a lot of sympathy for anyone hurt by type inference changes in the middle of those pipelines. Some of my ugliest rats nests of explicit any types and/or worse have been buried in RxJS pipelines next to // TODO and // HACK marker warnings to future spelunkers (myself included) about how much I was fighting the inferencing engine and losing in that particular combo of Typescript version and available typings. It's usually great when I can fix those later, and so far Typescript continues to move in that direction where those rats nests only get cleaner when I get a chance to revisit them. (But again, I sympathize with that existential fear that Typescript inferencing magic can sometimes take an unexpected step back until you understand why the change was made and how it benefits you elsewhere and/or once you figure out the root cause.)

Post reply on HN