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

21–30 of 149 posts

Re: Google Feedback on TypeScript 3.5

#21

Post by jmillikin »

Dobbs wrote: post #13
psv1 wrote: post #9

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

Google is pretty notorious for this. It is one of the reasons behind the old golang GOPATH setup, and one of the reasons it took so long for the Go taking so long to get modules.

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.

Re: Google Feedback on TypeScript 3.5

#22

Post by rat9988 »

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…

The real problem with shifting where it appears is when the error message is not helpful. With good error messages, it's not enough of a problem to justify leaving type inference in my opinion.

Re: Google Feedback on TypeScript 3.5

#23

Post by cptwunderlich »

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?

Re: Google Feedback on TypeScript 3.5

#24

Post by owl57 »

k__ wrote: post #19
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…

>this code is relying on inference too much Is this some TypeScript joke I'm too Hindley-Milner to understand?

Not sure. Once upon a time I wrote a small program in Haskell for an exercise in cryptography. It defaulted to Word8 for all arithmetic throughout the program because some of the operands came from a ByteString. Scary. Maybe you are less too Hindley-Milner and more following the advice of explicit types on at least all top-level declarations?

Re: Google Feedback on TypeScript 3.5

#25

Post by slifin »

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

Re: Google Feedback on TypeScript 3.5

#26

Post by stefano »

GiorgioG wrote: post #20
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…

C# (with .NET Core 3.0 officially launching on the 23rd of September, Blazor (WASM) support is included.) I have been playing around with Blazor a bit with the preview releases and I have to say it's pretty slick.

Did they improve the download size?

Re: Google Feedback on TypeScript 3.5

#27

Post by pornel »

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…

They pain of "unexpected any" they have doesn't come just from the type inference, but from gradual typing that makes it "too much". Without unknown/any being allowed to spread everywhere, the inference would have failed sooner, and the error/confusion would be contained (e.g. Rust stops on an ambiguous method call, plus limits implicit inference to function boundaries).

Re: Google Feedback on TypeScript 3.5

#28

Post by HDevo »

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 closest things I know of are Clutz and Gents, maintained here: https://github.com/angular/clutz.

They work with Closure-annotated JS (with JSDoc) though; not sure if it fits your use case.

Re: Google Feedback on TypeScript 3.5

#29

Post by klodolph »

pornel wrote: post #27
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…

They pain of "unexpected any " they have doesn't come just from the type inference, but from gradual typing that makes it "too much". Without unknown/any being allowed to spread everywhere, the inference would have failed sooner, and the error/confusion would be contained (e.g. Rust stops on an ambiguous method call, plus limits implicit inference to function boundaries).

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.

Re: Google Feedback on TypeScript 3.5

#30

Post by arlk »

heavenlyhash wrote: post #15
psv1 wrote: post #9

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

Be careful not to mistake Google's use of a monorepo with consideration of whether $DAYJOB or $FOSSPROJECT should use a monorepo. Google has a lot of tooling and some very thoroughly-considered and reinforced policies and cultures around their use of a monorepo. Trying to use a monorepo without those tools and ingrained policies may not be very likely to lead to similar results.

for reference https://ai.google/research/pubs/pub45424
Post reply on HN