81–90 of 245 posts
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.
https://medium.com/dartlang/dart-3-1-a-retrospective-on-func...
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 ? : } ) ```
Earlier quoted context omitted.
that's not using `try` as an expression. can you do `let foo = try (plus some handling for diverging in the other case?)`
It can and you in fact either have to mark that you return that error when you use try, or you have to provide a default value in a catch block: fn potentiallyErrorReturningFunc() !u64 { ... } const foo = potentiallyErrorReturningFunc() catch { 0 }; One notable difference to most other languages is it being a value only, basically a product type of return value XOR error. These error values get serialized into a numb…
Nitpick, but AFAIK this won't work and needs to be rewritten either to:
const foo = potentiallyErrorReturningFunc() catch 0;
const foo = potentiallyErrorReturningFunc() catch blk: { break :blk 0; }
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.
They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
Earlier quoted context omitted.
I see ‘TS server has been restarted 5 times in 5 minutes’ daily.
I don’t see this and I work on large enterprise websocket server with almost a million daily active users. In fact, I think we had 100% up time for the last 12 months except for a few AWS outages. Codebase is 10 years old and was CoffeeScript -> ES6 -> TypeScript.
Earlier quoted context omitted.
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.
> aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
Totally different meaning.
Earlier quoted context omitted.
> aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
> the fact they aren't syntax sugar over prototypes was a mistake Totally different meaning.
Earlier quoted context omitted.
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.
There is a (now inactive) "interface-types" proposal, which has dissolved into "component-types", but this scope-creep definitely is already quite concerning:
I really don't know what the author means by "language-centric" vs "implementation-centric" and "production-ready"...
implementation-centric: the language you are compiling is mostly fixed and/or defined by an external entity. You want to build the fastest compiler for this language, which emits the fastest code.
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…
My fantasy for the past year has been, if I could magically program anything, bringing a compiler and spec wholesale into the world out of the void, I would create a new language (call it WebScript as a placeholder) that
- featured an ML style type system, ADTs, a type syntax nearly indistinguishable from TypeScript
- whose actual core language essentially resembled Kotlin or "Go with exceptions"
- compiled to WASM or JS as a compatibility bridge
Nothing radical. Nothing revolutionary. Just these things would be an immediate plus.
But maybe AssemblyScript is a good enough step towards that.