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

71–80 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#71

Post by scotty79 »

jve wrote: post #25
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 { … }

Yes! This just drives me crazy: string something = null; try { something = mayThrow(); } catch (SomeException ex) { log.Info(ex); } catch (Exception ex) { log.Fatal(ex); throw; } if (something != null) { ... } Would be actually nice if it had F#'s try...with https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... and would allow us something like: var something = try { mayThrow() } with (SomeException ex) { l…

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

Re: TypeScript is surprisingly ok for compilers

#72

Post by mcluck »

supriyo-biswas wrote: post #7
rtpg wrote: post #4

TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)

There’s https://swc.rs/ , a Rust implementation (albeit without type checking at this time).

Not really a fair comparison. Stripping out types is trivially fast regardless of the implementation language. The _vast_ majority of the time taken in tsc is because of the type checking

Re: TypeScript is surprisingly ok for compilers

#74

Post by flohofwoe »

junon wrote: post #69
flohofwoe wrote: post #63

Earlier quoted context omitted.

"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).

I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.

Coming into web development fairly recently (after 2013 or so) from the statically typed hemisphere and without closely following the Javascript history from the start I naturally cannot agree ;)

(things like the scoping rules for 'var' is just bizarre, same with the concept of 'prototypes')

Looking at typical "old-school" Javascript code gives me the creeps the same way as looking at K&R C code ;)

Re: TypeScript is surprisingly ok for compilers

#75

Post by vlakreeh »

tomp wrote: post #55

As the post nicely demonstrates, TypeScript is definitely not OK for compilers (and not surprising at all!) It doesn't even have destructuring pattern matching! At this point, even Java is better [1]. [1] https://github.com/tomprimozic/caya/blob/master/src/caya/Int...

With how powerful the type system is you can implement pattern matching via a library pretty convincingly, https://github.com/gvergnaud/ts-pattern is definitely the go-to. That being said pattern matching is hardly a requirement for being ok for implementing compilers.

Re: TypeScript is surprisingly ok for compilers

#76

Post by flohofwoe »

zkldi wrote: post #33
thdespou wrote: post #27

Earlier quoted context omitted.

Zig can though: const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); }

that's not using `try` as an expression. can you do `let foo = try (plus some handling for diverging in the other case?)`

Yes, 'try' can be used like an expression in Zig which resolves to the unwrapped success-result of an error-union, or in case of an error immediately passes the error-result up to the calling function.

Re: TypeScript is surprisingly ok for compilers

#77

Post by baq »

scotty79 wrote: post #71
jve wrote: post #25

Earlier quoted context omitted.

Yes! This just drives me crazy: string something = null; try { something = mayThrow(); } catch (SomeException ex) { log.Info(ex); } catch (Exception ex) { log.Fatal(ex); throw; } if (something != null) { ... } Would be actually nice if it had F#'s try...with https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... and would allow us something like: var something = try { mayThrow() } with (SomeException ex) { l…

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

Re: TypeScript is surprisingly ok for compilers

#78

Post by LudwigNagasena »

flohofwoe wrote: post #60
xvilka wrote: post #48

Earlier quoted context omitted.

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

Any non-toy WASM application running in browsers will almost certainly end up as a hybrid WASM/JS application, just because you can't call directly from WASM into browser APIs, and even if the JS shim is "hidden from view", sometimes it's either more convenient or even more performant to write more than just a thin API shim in Javascript, especially for asynchronous code or to avoid redundant copying of large data bl…

> just because you can't call directly from WASM into browser APIs

Surely that will change someday.

Re: TypeScript is surprisingly ok for compilers

#79

Post by baq »

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 ? : } ) ```

for me the point is to be able to return from inside multiple expressions from the correct scope i.e. the root function without throwing.

Re: TypeScript is surprisingly ok for compilers

#80

Post by baq »

junon wrote: post #69
flohofwoe wrote: post #63

Earlier quoted context omitted.

"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).

I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.

you can still write the old javascript. it'll feel very lonely, though.
Post reply on HN