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

31–40 of 149 posts

Re: Google Feedback on TypeScript 3.5

#31

Post by GordonS »

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…

Fable (https://fable.io) is perhaps another option - it compiles F# to JavaScript.

Re: Google Feedback on TypeScript 3.5

#32

Post by k__ »

owl57 wrote: post #24
k__ wrote: post #19

Earlier quoted context omitted.

>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?

Could be, yes :)

Re: Google Feedback on TypeScript 3.5

#33

Post by apalmer »

psv1 wrote: post #9

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

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.

Re: Google Feedback on TypeScript 3.5

#34

Post by rkangel »

klodolph wrote: post #29
pornel wrote: post #27

Earlier quoted context omitted.

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.

> 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).

Re: Google Feedback on TypeScript 3.5

#35

Post by rkangel »

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…

Have you looked at ReasonML/OCaml? It certainly compiles well for web (bucklescript) and desktop. I haven't tried it for mobile but I would be surprised if it didn't work well.

The ReasonML native tooling (i.e. non-web) is evolving, but it's fundamentally sugar on top of a long solid history of OCaml.

Re: Google Feedback on TypeScript 3.5

#36

Post by rkangel »

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…

Dart is one option, and Flutter means that you can share UI code as well. Dart is a fundamentally boring language (in a good way). If you have any experience of OO langauges it will take about 10 minutes to pick up. I missed union types and pattern matching from FP, but otherwise it works well.

Re: Google Feedback on TypeScript 3.5

#37

Post by cutler »

stefano wrote: post #26
GiorgioG wrote: post #20

Earlier quoted context omitted.

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?

No and on that basis it's unusable. However that's because it downloads the whole runtime. Eventually MS intend to load only your compiled code.

Re: Google Feedback on TypeScript 3.5

#38

Post by fluffything »

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…

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 place to do that.

Re: Google Feedback on TypeScript 3.5

#39

Post by larzang »

apalmer wrote: post #33
psv1 wrote: post #9

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

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.

Whether it's a monorepo or not doesn't change the fact that you have a billion lines of code to maintain, but at least this way they're forced to make changes consistently. The alternative would be doing it piecemeal with a dozen versions of dependencies propagating due to fragmentation, which is way way worse.

Re: Google Feedback on TypeScript 3.5

#40

Post by rkangel »

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.

The default should be keeping code together, and justifying why you are splitting it up, not the other way around.

While what you said is true, the codebase of most organisations is not large enough that they run into those scale constraints for a long time. Instead, if you split up your code you immediately get organisational headaches of managing changes across multiple codebases. If you keep it together, the scale challenges can be managed later, if they occur (c.f. YAGNI).

If you are splitting, codebases should be split across organisational boundaries, not technical ones. If you look at the FOSS world, the obvious conclusion is that each library is in its own repo, and that is partly true. In practice what is happening is that each OSS project is its own organisational team, and so it lives together. If you have parts of your company on different continents working on different things (and maybe you need different access) then splitting up may make sense. Otherwise, you're probably just making your life harder for little to no gain.

Post reply on HN