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

111–120 of 149 posts

Re: Google Feedback on TypeScript 3.5

#111

Post by papln »

rkangel wrote: post #34
klodolph wrote: post #29

Earlier quoted context omitted.

I feel this is a lesson every Haskell programmer goes through. Most Haskell programmers I know write types for all of the top-level declarations. Although it usually isn't necessary, it makes drastic improvements to the quality of error messages.

> Although it usually isn't necessary, it makes drastic improvements to the quality of error messages. It also provides valuable documentation. You can usually work out what a function does from just its type (and quite often, that's all you have to work with).

> just its type (and quite often, that's all you have to work with).

which is a weakness in the culture of Haskell library authors and/or the ecosystem for contributing documentation patches.

Re: Google Feedback on TypeScript 3.5

#112

Post by andrejk »

htgb wrote: post #95
patates wrote: post #89

Earlier quoted context omitted.

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.

I agree, as a mostly C# developer for years, then Typescript (Node, Angular and React) for the last couple of years, when I go back to C# projects, I feel like I'm doing a lot of work for the compiler. And really elegant use of the TS type system doesn't translate well into C# many times, forcing me to write boilerplate.

I've been eyeing F# for more elegant managed code, but that's going to take me a little more up-front investment to get productive.

Re: Google Feedback on TypeScript 3.5

#113

Post by papln »

y2bd wrote: post #90
msoad wrote: post #45

filter(Boolean) is a bad idea anyways. I was bitten by this before.

Why do you say so?

One reason:

This isn't TS-specific; it's common in Python too: coercing to Bool has language semantics (for whatever language you are in) which often don't match the application semantics of your program. Application programmers don't (and shouldn't have to, but for the language's over-eager coercions) always think about the boolean semantics of all their objects. In particular, None and empty/zero object are both False in Python, and Python style/linters push you to avoid explicit comparison to None, which gets weird when your application wants to treat empty objects as True because they have differen semantics from None. (For example, in a security function, None may mean no-op / fallback to default, but Empty might mean "Reject all".

Re: Google Feedback on TypeScript 3.5

#114

Post by papln »

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.

On the contrary, having multiple-versions could have made the upgrade much worse, by deferring compatibility problems from submit time to deploy time.

Re: Google Feedback on TypeScript 3.5

#115

Post by papln »

nih0 wrote: post #65
jmillikin wrote: post #21

Earlier quoted context omitted.

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?

I think it's the mentioned

> multiple Go packages in one directory

as opposed to having a 1:1 package:dir mapping

Re: Google Feedback on TypeScript 3.5

#116

Post by papln »

yoz-y wrote: post #47
apalmer wrote: post #33

Earlier quoted context omitted.

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.

Or you can YOLO / Leroy Jenkins the change and let everyone else fix the breakage you create, or see if they demand a rollback.

Re: Google Feedback on TypeScript 3.5

#117

Post by juliendc »

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 between the backend and the frontend in web applications. It's still hard to fully type the entire flow from the database calls with the ORM to the objects manipulation in the frontend.

How are you dealing with that? We used Nexus with GraphQL but it was still a bit cumbersome.

Re: Google Feedback on TypeScript 3.5

#118

Post by [deleted] »

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…

[deleted]

Re: Google Feedback on TypeScript 3.5

#119

Post by olmo »

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…

Glad to see someone pints this out. That’s the main reason I use React + Typescrip. JSX is an extension of javascript and can be fully checked while any template language is a custom invention that it’s hardly toolable.

Re: Google Feedback on TypeScript 3.5

#120

Post by evmar »

whatshisface wrote: post #102
evmar wrote: post #78

Earlier quoted context omitted.

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.

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