Live data from Hacker News

TypeScript 3.5

devblogs.microsoft.com

71–80 of 88 posts

Re: TypeScript 3.5

#71

The 2 big things missing on typescript: 1) Operator overloading 2) Runtime type checking of JSON payloads (on dev env at least) Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2 And the most common error that it should help catch during development is that you get a JSON and you cast it but it means no…

1) If your motivation is heavy mathematical programming then I hear you, but beware that you are the minority of the language's userbase, (more generally, most application-level programming languages' userbase), it's not something most people care about.

If you want to write clever DSLs and/or name methods in ways that save keystrokes like in scala, NO, please.

2) There are libraries such as runtypes and io-ts that integrate well with the static type system

Re: TypeScript 3.5

#72

Earlier quoted context omitted.

The explicit goal of TypeScript is to be JavaScript, with types — i.e. not introduce any features not likely to land in an ECMAScript spec.

Which is a shame because JavaScript is constrained due needing backwards-compatibility above all (among other issues) but TypeScript isn't

Not much of a shame IMO - there are plenty of other languages that transpile to JS without those goals, if you don't care about backwards compatability and 1:1 mappings to vanilla JS.

On the other hand, there's only one language that I'm aware of - TypeScript - prioritizing these things, which is a major selling point of it to me. I don't want yet another leaky abstraction, or yet another runtime heavy enough for those abstractions to not leak.

I just want enough types for my intellisense to work right, and for my sorry ass - spoiled by years of nothing but static typing systems - to be able to code without drowning in a veritable sea of uncaught type errors to debug, when I poke frontend stuff.

Re: TypeScript 3.5

#73

The 2 big things missing on typescript: 1) Operator overloading 2) Runtime type checking of JSON payloads (on dev env at least) Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2 And the most common error that it should help catch during development is that you get a JSON and you cast it but it means no…

RE: JSON: I've started tagging my JSON blobs as `unknown` and then using type guards (typeof, instanceof, field access existence checks, Array.isArray checks, user defined type guards[1], etc.) my way to inferring the shape of that JSON blob is as expected, and it seems to work pretty well.

[1] https://www.typescriptlang.org/docs/handbook/advanced-types....

Re: TypeScript 3.5

#74

Earlier quoted context omitted.

Which is a shame because JavaScript is constrained due needing backwards-compatibility above all (among other issues) but TypeScript isn't

Not much of a shame IMO - there are plenty of other languages that transpile to JS without those goals, if you don't care about backwards compatability and 1:1 mappings to vanilla JS. On the other hand, there's only one language that I'm aware of - TypeScript - prioritizing these things, which is a major selling point of it to me. I don't want yet another leaky abstraction, or yet another runtime heavy enough for tho…

Hello See also how you can start making steady daily passive incomes on virta stock trading without you risking your money and your investment visit the website here http://www.virtatrade.com/index.php for more details

Re: TypeScript 3.5

#75

Earlier quoted context omitted.

Which is a shame because JavaScript is constrained due needing backwards-compatibility above all (among other issues) but TypeScript isn't

Not much of a shame IMO - there are plenty of other languages that transpile to JS without those goals, if you don't care about backwards compatability and 1:1 mappings to vanilla JS. On the other hand, there's only one language that I'm aware of - TypeScript - prioritizing these things, which is a major selling point of it to me. I don't want yet another leaky abstraction, or yet another runtime heavy enough for tho…

Typed and those features? there isn't a single one. But yeah, maybe what I need is a fork of TypeScript with those features (or maybe some sort of plugin)

Re: TypeScript 3.5

#76
post #70

Earlier quoted context omitted.

You know it would be completely transparent right? Just gets transpiled into .__add__(obj)

We already saw this play out in Scala. People end up abusing these to create absolutely unreadable "DSL"s. Even when it's tastefully done, for example the "!" and "?" operator for messages in Akka, it's not better than the names "tell" and "ask".

Fair enough.

Re: TypeScript 3.5

#77
post #66

Earlier quoted context omitted.

Is this not what enums with associated values are?

Probably... but in any case TypeScript also supports naked (edit: I just made up the name) unions, where you don't need to declare them upfront, and where values of different types can be included directly. Such as: let a = random() ? 'a' : 1 TypeScript infers type string | number

This is still a discriminated union, only that the discriminator is provided by Javascript and is thus hidden: it's `typeof`.

Re: TypeScript 3.5

#78
post #66

Earlier quoted context omitted.

Probably... but in any case TypeScript also supports naked (edit: I just made up the name) unions, where you don't need to declare them upfront, and where values of different types can be included directly. Such as: let a = random() ? 'a' : 1 TypeScript infers type string | number

This is still a discriminated union, only that the discriminator is provided by Javascript and is thus hidden: it's `typeof`.

Yeah, that's the runtime perspective... but for the type system, they're different... with the "naked" union being much harder (as they're non-algebraic - `a | b | b` always equals `a | b` and might even equal just `a` for some values of `a` and `b`)

Re: TypeScript 3.5

#79
post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

[deleted]

Re: TypeScript 3.5

#80
post #25

Earlier quoted context omitted.

Very specifically, 3.4 had a few perf regressions for some type signatures [1]. More generally, TS can be a bit slow (~seconds) especially for large webapp development if you need hot-reloading and such. There are tricks to emit without checking and doing async checking during the dev process which speeds things up quite a bit. [1] https://github.com/Microsoft/TypeScript/issues/30663

I'm using 3.5.1, the issue is I don't have very many files and it's in a Node environment where it transpiles the file to the output directory with no bundling or hot reloading included. What are some of these tricks to skip checking or do async checking? I did a quick search and came up with a GitHub issue [0] for adding the option to skip checking, but didn't see anything myself. [0] https://github.com/Microsoft/Ty…

Theres tooling for this for webpack described: https://github.com/TypeStrong/ts-loader#faster-builds

More generally though you have two loops one that does transpileOnly and one that doesn't. The latter is your type check process.

Post reply on HN