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

131–140 of 149 posts

Re: Google Feedback on TypeScript 3.5

#131

Post by WorldMaker »

breatheoften wrote: post #98
jchw wrote: post #63

Earlier quoted context omitted.

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

Yes, my advice is almost always strict should be true for every new project, and even sometimes for migration projects where the end goal is to absolutely decrease tech debt and bugs as quickly as possible and the team isn't afraid of a giant compiler error waterfall as motivation. (It's a nice auto-generated TODO list with some semblance of progress reporting!) But at the very least, everyone should do themselves the favor and "noImplicitAny: true" no matter if it's new, migration, something inbetween, and no matter what they think of any of the other strict flags. Explicit anys are searchable TODO markers and fine, but implicit anys always seem to be hidden bugs waiting to be found.

Re: Google Feedback on TypeScript 3.5

#132

Post by cutler »

dominotw wrote: post #68
cutler wrote: post #41

Earlier quoted context omitted.

Good luck untangling re-native built on re-frame built on Reagent built on shadow-cljs built on React native built on React built on Android/iOS when one of those parts change.

so in that equation applies to all of JS transpilers. Why this a clojurescript specific complaint?

Because Clojurescript adds at least another 3 layers of indirection.

Re: Google Feedback on TypeScript 3.5

#133

Post by cutler »

mattferderer wrote: post #56
cutler wrote: post #37

Earlier quoted context omitted.

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.

You can avoid that issue with the Server Side Blazor concept for business side portions of your application. Depending on the application you can get extremely far with just using HTTP requests to an API for anything business logic related. A lot of apps over complicate themselves by trying to force a JS framework on the front end with no benefit to the user. I seem to prefer using non-SPAs these days over SPAs becau…

As I understood Blazor as compiled business logic rather than a bundled runtime is due in a future release of .Net Core. Not sure if it's ready for 3.0 later this month but that will be the game-changer Blazor promises to be. Yes, Phoenix Live View is similar but unfortunately Elixir hasn't really captured sufficient mindshare for it to have an impact.

Re: Google Feedback on TypeScript 3.5

#134

Post by WorldMaker »

jannes wrote: post #60
Rychard wrote: post #52

Earlier quoted context omitted.

I don't have a significant amount of experience with TypeScript, but even from my limited experience I agree that it's a fantastic product. That said, at $JOB we (unfortunately) have a fair amount of production code written in TypeScript 0.9 which nobody has ever upgraded, and simply won't compile on a more recent version. It's been that way for years now, and every attempt to bring it up to date has been met with fa…

You can see a list of all changes in the "What's New in TypeScript" document on GitHub: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T... And a list of breaking changes here: https://github.com/microsoft/TypeScript/wiki/Breaking-Change... They both go back until v1.1. For older changes you can check the blog: https://devblogs.microsoft.com/typescript/announcing-typescr... https://devblogs.microsoft.com/…

> 2. Pre-1.5 TypeScript had something called "internal modules" which were renamed to "namespaces" and are generally discouraged now. Hopefully your code is not using that feature.

Related to this, the TypeScript pre-1.0 import/export syntax for "external modules" was grandfathered in, but the semantics changed alongside the "internal modules" changes in 1.5. So pre-1.0 import/exports still mostly "compile" in post-1.5, but have very different semantics and that can often cause a lot of downstream module shape headaches, depending (and exacerbated by) the module format you are targeting.

A first pass making sure to rewrite all import/require/export statements can save you a lot of work later, even though it won't directly cause compile errors. You can get some compile errors by making sure you try to compile to a "proper" post-ES2015 module format (--module esm or --module es2015 or --module esnext even). There's also tslint rules such as "no-import-requires".

Re: Google Feedback on TypeScript 3.5

#135

Post by evmar »

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…

Angular has been working on type-checking the templates: https://blog.angularindepth.com/type-checking-templates-in-a...

Disclaimer: I have heard about the above enough to dig up a random blog post about it but I don't know a lot about how it works.

I think in JSX (and I've seen experiments with lit too) there is also integration between the template and type checker.

Re: Google Feedback on TypeScript 3.5

#136

Post by evmar »

bpicolo wrote: post #100
Nitramp wrote: post #97

Earlier quoted context omitted.

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.

You might try out https://github.com/theseanl/tscc , which aims to do this.

Re: Google Feedback on TypeScript 3.5

#137

Post by WorldMaker »

papln wrote: post #113
y2bd wrote: post #90

Earlier quoted context omitted.

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 Fa…

Another reason that is TS-specific is that of JS functions can be highly variadic in the number of arguments and a lot of subtle runtime bugs can be found in blindly passing arguments without checking their count. If filter changes from returning only one thing to say two (for instance, an index count), Boolean may produce a runtime error for having too many arguments, may silently ignore extra arguments, may interpret an extra argument as changing the behavior, or some combination of all three depending on strictness versus compatibility level, executing browser, phase of the moon, etc.

Boolean itself I've not had trouble with, but things like map(parseInt) is the big one that bites a lot of junior developers all the time in TS/JS. (parseInt takes an optional second argument for radix, so in cases where the second argument returned by map is an index count, which is likely, you get it parsing in base-0, base-1, base-2, … which is almost never something you'd do intentionally.)

Re: Google Feedback on TypeScript 3.5

#138

Post by kyrra »

papln wrote: post #114
kyrra wrote: post #62

Earlier quoted context omitted.

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.

It's a trade-off. As a user of a third-party library, I would like to upgrade it to get new functionality. But there are breaking changes in the update.

So to upgrade I would have to fix all users of the library to upgrade. While this is better overall for the codebase, it can put a lot of work on others for a not well maintained third-party library. Something like TS has people that help keep it updated. But for something more obscure, it'll be on someone else who cares enough to put in the work.

Re: Google Feedback on TypeScript 3.5

#139

Post by squiggleblaz »

fluffything wrote: post #38
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 pla…

The compiler should be capable of inferring the type as far as reasonably possible. But it should be an error to not specific the types of top level functions and class methods.

This way, when you write

    const f = (a, b) => a + b
the compiler can tell you to write:

    const f => (a: T, b: T): T => a + b
or

    const f : (a: T, b: T) => T
            = (a, b) => a + b
This would be effectively like GHC's typeholes, where the compiler will tell you what to write when you say

    f :: _
    f a b = a  b
except that rather than being an optional step by a developer, it's a mandatory standard.

(Well, I don't think typescript infers that type for that function, but whatever it actually infers, that's what should be there in the error message.)

Re: Google Feedback on TypeScript 3.5

#140

Post by jbverschoor »

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.

> appropriate places This
Post reply on HN