Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.7

typescriptlang.org

Post reply on HN
Print view View original

141–150 of 167 posts

Re: TypeScript 3.7

#141

Post by jkoudys »

evangow wrote: post #90
reggieband wrote: post #71

I'm a big fan of the new operators. One of my remaining gripes with Javascript/Typescript is the try/catch mess around await. It makes assignment of const a pain for async calls that may reject. e.g. let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } // at this point result is `SomeType | undefined` if (result) { doSomething(result); } I really want some ki…

I use await-to-js[1] to clean this stuff up. You can pair it with destructuring arrays like so: const [err, result] = await to(funcThatReturnSomeType()); if(err) doSomethingWithErr(err); doSomething(result); [1] https://www.npmjs.com/package/await-to-js

This right here is exactly why Errors should be enums, instead of this wacky exception handling system. Try/catch is why I frequently prefer plain old .then and .catch instead

Re: TypeScript 3.7

#142

Post by jkoudys »

snypox wrote: post #114
evangow wrote: post #90

Earlier quoted context omitted.

I use await-to-js[1] to clean this stuff up. You can pair it with destructuring arrays like so: const [err, result] = await to(funcThatReturnSomeType()); if(err) doSomethingWithErr(err); doSomething(result); [1] https://www.npmjs.com/package/await-to-js

Good old Go-style

Yep. Doesn't even feel so different from using error first callbacks. I had to go back to using them for something recently, and feel like most of my problems back then stemmed from excessive deep nesting, and overreliance on the closure scope. Don't get me wrong I love the Promise api, but if ts were popular pre-Promises, we wouldn't have had half the issues with callbacks for concurrency. You'd be able to type functions that take callbacks, know what errors they can receive, see if anything's out of scope or misused, etc

Re: TypeScript 3.7

#143

Post by jkoudys »

erikpukinskis wrote: post #91
nicoburns wrote: post #56

Earlier quoted context omitted.

It's nice for situations where you want to access a deeply nested prop, and you only care whether the whole path is there or not. Saves you having to add a seperate check for every level of the hierarchy. e.g. You can do: foo?.bar?.baz || "default"; Rather than: (foo && foo.bar && foo.bar.baz) || "default"; Agree that developers can be careful about nullability (in fact I pulled someone up on this in a code review ea…

The problem is that if you find yourself needing deep accessors, something is very wrong with your scopes. You are reaching across many levels of concerns which is a code smell. So, by making it “nice” you are making a code smell less smelly, which feels good in the moment, at the syntax level, but makes your code worse at the architecture level. This is roughly the story for all of ES6... make it “nice” to work with…

I agree that the main scenarios people are excited for are probably the exact opposite of the ones we should be looking to solve with this. Indeed my last comment right before posting this was about how callbacks are better than we remember (and if we were on ts when using them, probably wouldn't have minded at all).

Deeply nested object props are often bad, except for when it's a big dynamically-defined object (eg a directory tree that you would traverse with lodash get). It's also great when you're not deeply nested, you're simply checking for the inclusion of something in a collection that is itself optional. Eg a Map#has on an optional map.

Re: TypeScript 3.7

#144

Post by davnicwil »

paulddraper wrote: post #104
achou wrote: post #67

I just did some refactoring on a medium size code base and here are a few things to watch out for when adopting optional chaining and the new null coalescing operator: foo && await foo(); is not the same as await foo?.(); this will work in most cases but subtly, the await wraps the undefined case into a Promise, while the original code would skip the await altogether. String regular expression matching returns null,…

&& ?. || ?? It's a shame JS at the beginning doubled down on the "billon dollar mistake" [1] with two(!) kinds of NULL instead of just using Maybe/Option. Ah well, if it were good it wouldn't be popular :/ [1] https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

I don't see it as two kinds of null, there is a null value, and then there is the fact that no value has ever been defined, which is undefined.

It can be useful to have the latter case distinguished in a dynamic language because it can enable certain powerful patterns. At the end of the day, compressing both these cases to a single concept of null would be lossy. This may have certain advantageous implications for simplicity, but you're trading that off for language power. Which you favour more of course depends on the usecase.

Re: TypeScript 3.7

#145

Post by realharo »

int_19h wrote: post #98
grapehut wrote: post #41

Earlier quoted context omitted.

Definitely. It's a shame that dart gets so much unwarranted hate. I mean, I also think it's an absolutely awful language but it's really proven to be a valuable source of data for what other programming languages should do and perhaps more importantly: not do. I really hope we see a lot more things like Dart, and not so much negativity.

The use of ?? and ?. for null coalescing and null chaining comes from C#, and predates Dart.

According to https://docs.microsoft.com/en-us/dotnet/csharp/language-refe..., ?. was only added to C# 6.0, in 2015.

Groovy had ?. in at least 2005. Then there were CoffeeScript, Kotlin, Swift and a bunch of others in the meantime.

Not that it matters :)

Re: TypeScript 3.7

#146

Post by mateuszf »

lucideer wrote: post #140
vikingcaffiene wrote: post #109

Earlier quoted context omitted.

Sorry, JS? While JS might get this stuff one day, these language features are for TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. Speaking of which, optional chaining and null coalescence are core language features of some very good languages. K…

> TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. I'm afraid literally everything in this snippet is incorrect. The Typescript website opens with: > Typescript JavaScript that scales. Typescript is a typed superset of JavaScript that compiles to…

> Typescript is Javascript.

In the same way as an Animal is a Camel.

Re: TypeScript 3.7

#147

Post by vimslayer »

Zarel wrote: post #124
autora wrote: post #122

Earlier quoted context omitted.

> just happens to interop with It does not interop with JavaScript. > and in some scenarios transpile down to JavaScript It always transpiles to JavaScript and always runs as JavaScript. There is no such thing as a TypeScript runtime engine. TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for Typ…

> It does not interop with JavaScript. I don't know what you mean here, but it is certainly possible for TypeScript code to use JavaScript libraries and vice versa, which is presumably what most people mean by "TypeScript interops with JavaScript". > It always transpiles to JavaScript and always runs as JavaScript. Technically false... https://assemblyscript.org > TypeScript is a superset of JavaScript. Therefore the…

AssemblyScript is not TypeScript. Especially so if you don't consider TypeScript to be JavaScript; I'd argue that the difference between TypeScript and AssemblyScript is bigger than TypeScript and JavaScript.

Re: TypeScript 3.7

#148

Post by vimslayer »

KuhlMensch wrote: post #127
autora wrote: post #122

Earlier quoted context omitted.

> just happens to interop with It does not interop with JavaScript. > and in some scenarios transpile down to JavaScript It always transpiles to JavaScript and always runs as JavaScript. There is no such thing as a TypeScript runtime engine. TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for Typ…

This does not necessarily invalidate your wider points, but just FYI: > It does not interop with JavaScript. Hm, this depends on your definition of "interop". My JavaScript and TypeScript are languages that exchange information. The execution model ultimately involves JavaScript when I use tsc, but ultimately it also includes an interpreter. My user-space syntax doesn't care. > There is no such thing as a TypeScript…

Can you really consider Deno to be a "TypeScript runtime engine" when it compiles TypeScript to JavaScript and runs it in V8, a JavaScript engine.

Re: TypeScript 3.7

#149

Post by autora »

KuhlMensch wrote: post #127
autora wrote: post #122

Earlier quoted context omitted.

> just happens to interop with It does not interop with JavaScript. > and in some scenarios transpile down to JavaScript It always transpiles to JavaScript and always runs as JavaScript. There is no such thing as a TypeScript runtime engine. TypeScript is a superset of JavaScript. Therefore the OP's point is still valid. Any "mistakes" JavaScript might have made about having null AND undefined are also issues for Typ…

This does not necessarily invalidate your wider points, but just FYI: > It does not interop with JavaScript. Hm, this depends on your definition of "interop". My JavaScript and TypeScript are languages that exchange information. The execution model ultimately involves JavaScript when I use tsc, but ultimately it also includes an interpreter. My user-space syntax doesn't care. > There is no such thing as a TypeScript…

>Not being glib, just a heaps up: https://github.com/denoland/deno

interesting thanks for the heads up - my assumption is though that this is just a wrapper over a V8 engine with typescript compilation on the fly?

Does that make it a TypeScript runtime or not?

Re: TypeScript 3.7

#150

Post by Udik »

mateuszf wrote: post #146
lucideer wrote: post #140

Earlier quoted context omitted.

> TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. I'm afraid literally everything in this snippet is incorrect. The Typescript website opens with: > Typescript JavaScript that scales. Typescript is a typed superset of JavaScript that compiles to…

> Typescript is Javascript. In the same way as an Animal is a Camel.

If you're making general statements about animals, then they should also apply to a set of camels.
Post reply on HN