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

TypeScript is surprisingly ok for compilers

matklad.github.io

Post reply on HN
Print view View original

91–100 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#91

Post by macguillicuddy »

austin-cheney wrote: post #66
baq wrote: post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

Perhaps the place I use it most is that try/catch is how you deal with rejected promises that you've `await`ed in an `async` function.

Re: TypeScript is surprisingly ok for compilers

#93

Post by graftak »

crooked-v wrote: post #43
moonchrome wrote: post #12

Earlier quoted context omitted.

That's some very high level view - in reality even tough those languages are in similar categories the experience would be vastly different : TypeScript - powerful type system but shit underlying stdlib and language (no pattern matching/switch expressions) Dart - worse than TS because the object model is closed - so no dynamic freedom, but the type system and expressions are weaker then the rest. Also 0 meta programm…

> no pattern matching/switch expressions They're still waiting on the do expression proposal for that ( https://github.com/tc39/proposal-do-expressions ), which has been in the bikeshedding stage for the past five years.

The proposal for pattern matching syntax seems more akin to what they're looking for.

https://github.com/tc39/proposal-pattern-matching

Re: TypeScript is surprisingly ok for compilers

#94

Post by AgentME »

jillesvangurp wrote: post #45
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascrip…

Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to include a JS runtime). If that existed for general JS, browsers would just upgrade to use that internally on all JS.

Well, you could in theory get benefits by having optimizations based on the type declarations. This could be awkward to do when Typescript allows zero-runtime-cost interop with untyped JS anywhere and allows any value to be cast through the `any` type and then to any other type. If Typescript with these optimizations is still intended to execute in the same way as its untyped JS equivalent, then the optimizations all need to handle being opted out of when an unexpected value is received, in the same way optimizing runtime-type-tracking JS engines have to be able to abort out of their type-based optimizations. This optimization would be equivalent to pre-warming a JS engine's knowledge of runtime type information, which is an optimization that could be done for JS in general rather than by doing it just in the Typescript project through compiling to WASM.

Re: TypeScript is surprisingly ok for compilers

#95

Post by jve »

baq wrote: post #77
scotty79 wrote: post #71

Earlier quoted context omitted.

var something = (() => { try { return mayThrow() } catch(SomeException ex) { log.Info(ex); return null; } catch(Exception ex) { log.Fatal(ex); throw; } })(); Close enough?

not really; can't immediately return from the lambda caller without throwing, always have to either try/catch anyway or if/else the return value of the lambda. (also, it's rather ugly to read and inconvenient to write.)

Another idea, introduce ??? that would invoke on exception :)

   var something = (mayThrow()
      ??? (SomeException ex) => { log.Info(ex); return null} )
      ??? (Exception ex) => { log.Fatal(ex); throw; };
Or maybe just start using Results as return type and get ValueOrDefault :) But when it comes to handling exceptions, I think it explodes there with ifs and processing IENumerables: https://github.com/altmann/FluentResults

But then again, simpler Results wrapper may be used perhaps. But it is a different way of coding and takes some mental shift on how to think about errors and distinguish between error results and true exceptions.

Oh, csharplang already had discussion on the matters about try/catch single statements: https://github.com/dotnet/csharplang/issues/786

Re: TypeScript is surprisingly ok for compilers

#96

Post by graftak »

yunohn wrote: post #68
crooked-v wrote: post #43

Earlier quoted context omitted.

> no pattern matching/switch expressions They're still waiting on the do expression proposal for that ( https://github.com/tc39/proposal-do-expressions ), which has been in the bikeshedding stage for the past five years.

I’m not clear on the benefits of this proposal over just using anonymous functions. Some of the examples just seem contrived. And the React example makes no sense, you can use a ternary and it is even shorter. ``` return ( {loggedIn ? : } ) ```

What if you want a `switch` instead?

Re: TypeScript is surprisingly ok for compilers

#97

Post by graftak »

chpatrick wrote: post #64
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

Type-refining if in TypeScript is good enough for pattern matching if you ask me.

The TypeScript type system meta programming actually does pattern matching very well, it’s just the underlying JS runtimes that can’t, there is a proposal for it though; https://github.com/tc39/proposal-pattern-matching.

Re: TypeScript is surprisingly ok for compilers

#99

Post by mgreenw »

domlebo70 wrote: post #24

To OP: You could avoid the visitor by using an IIFE style switch using the run utility fn: export const run = (f: () => T): T => f(); Now you can go: const inferred_type = run(() => { switch(blah) { ... } })

Exactly! I wrote a post about this pattern: https://maxgreenwald.me/blog/do-more-with-run

Re: TypeScript is surprisingly ok for compilers

#100

Post by AgentME »

hardware2win wrote: post #39

Ive been writing compiler in C# and I dont see anything fancy here except union type Ive personally decided to avoid visitor pattern bloat and Im waiting for closed enum feature in order to have compile time exhaustive check

I find myself really missing union types when I'm in a language that doesn't have either it or Rust-style enums. The usual alternatives are awkward: either one class representing the union type containing N nullable properties with the documented condition that only one property is ever expected to be non-null, a condition the type system isn't able to check or make use of, or multiple classes extending a common class, which feels really heavyweight. Both solutions require some duplication or clever composition if you want several different overlapping union types.
Post reply on HN