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

91–100 of 149 posts

Re: Google Feedback on TypeScript 3.5

#91

Post by tylerhou »

kyrra wrote: post #62
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.

This is also why Google says to test everything; even minor version upgrades can have unexpected behavioral changes. Without tests, these might break your project without warning.

Re: Google Feedback on TypeScript 3.5

#92

Post by vicapow »

_bxg1 wrote: post #88
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”.

Agreed. It seems to be endemic to Flow's culture. We use it at my company and the signal/noise ratio of helpful to unhelpful errors hovers around 0.5. A handful of simple flags to relax checks in specific, extremely common cases would cut out 80% of that noise, but requests on GitHub have been shot down in the name of "soundness". Things like allowing null to be implicitly cast to a string, or assuming document.body…

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.

Re: Google Feedback on TypeScript 3.5

#93

Post by lhorie »

vicapow wrote: post #92
_bxg1 wrote: post #88

Earlier quoted context omitted.

Agreed. It seems to be endemic to Flow's culture. We use it at my company and the signal/noise ratio of helpful to unhelpful errors hovers around 0.5. A handful of simple flags to relax checks in specific, extremely common cases would cut out 80% of that noise, but requests on GitHub have been shot down in the name of "soundness". Things like allowing null to be implicitly cast to a string, or assuming document.body…

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.

GP is saying they would like for flow to offer some leeway for things like this: https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNA... (i.e. not nag on a "technically-it-could-be-non-string-but-I-know-for-a-fact-that-this-is-fine")

LSP is kinda irrelevant to the argument that they feel that TS+VSCode is geared towards real-world productivity, vs the feeling that Flow prioritizes academic goals over devexp.

Re: Google Feedback on TypeScript 3.5

#94

Post by _bxg1 »

lhorie wrote: post #93
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.

GP is saying they would like for flow to offer some leeway for things like this: https://flow.org/try/#0MYewdgzgLgBAZiEMC8MDaByBIMF0DcAUKJLNA... (i.e. not nag on a "technically-it-could-be-non-string-but-I-know-for-a-fact-that-this-is-fine") LSP is kinda irrelevant to the argument that they feel that TS+VSCode is geared towards real-world productivity, vs the feeling that Flow prioritizes academic goals over devexp.

Correct. JavaScript is fundamentally flexible on certain things, and while it's very helpful to have some assistance with taming that wilderness, it will fundamentally never be perfect, and by fighting the language tooth and nail on things that don't matter, one only creates developer pain.

Re: Google Feedback on TypeScript 3.5

#95

Post by htgb »

patates wrote: post #89
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…

I'm writing this as a developer who writes a lot of C# and Typescript: Have you tried C#? Even though I sometimes miss the flexibility of Typescript when writing in it, I love the reliability. Maybe it's no as battle-tested as Java (especially with all the rewrites recently), but feels like it's 99.9% there.

Not GP, but as a developer working with TypeScript and C#, I respectfully disagree regarding the type system. There are many things I like better in C# compared to JavaScript, but I feel overly constrained by the type system of C# way more often, and most notable is the lack of discriminated unions (aka sum types etc). You can say that something has this and that, but not that it is this or that.

Re: Google Feedback on TypeScript 3.5

#96

Post by _bxg1 »

vicapow wrote: post #92
_bxg1 wrote: post #88

Earlier quoted context omitted.

Agreed. It seems to be endemic to Flow's culture. We use it at my company and the signal/noise ratio of helpful to unhelpful errors hovers around 0.5. A handful of simple flags to relax checks in specific, extremely common cases would cut out 80% of that noise, but requests on GitHub have been shot down in the name of "soundness". Things like allowing null to be implicitly cast to a string, or assuming document.body…

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 of a .find() or a maybe-property on an object type, I now have to add null checks (or at best || '' fallbacks) everywhere, muddling up my code and making it harder to follow.

Re: Google Feedback on TypeScript 3.5

#97

Post by Nitramp »

bpicolo wrote: post #48
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

Yes, we use that to use TS together with Closure for all our TS code at Google.

It's a bit difficult to hook up though, and we haven't had the cycles to make the open source version user friendly, I'm afraid :-(

Re: Google Feedback on TypeScript 3.5

#98

Post by breatheoften »

jchw wrote: post #63
cypressious wrote: post #50

Earlier quoted context omitted.

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.

In my experience a lot of people don’t necessarily start projects with strict mode — and they _really really_ should ... most people I’ve talked to who couldn’t figure out how to use typescript never figured things out because they ended up somehow with a compiler configured with noImplicitAny: false — typescript really needs to find a way to change the default here ...

Re: Google Feedback on TypeScript 3.5

#99

Post by gmoot »

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.

Re: Google Feedback on TypeScript 3.5

#100

Post by bpicolo »

Nitramp wrote: post #97
bpicolo wrote: post #48

Earlier quoted context omitted.

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

Yes, we use that to use TS together with Closure for all our TS code at Google. It's a bit difficult to hook up though, and we haven't had the cycles to make the open source version user friendly, I'm afraid :-(

It would be really cool to see the user-friendly version (though that might lead to a rabbit hole on the Closure side, too). The Closure compiler remains awesome, just difficult to make use of successfully.
Post reply on HN