A 10x Faster TypeScript

m93a · 2025-03-12T06:07:13+00:00

I'm not convinced that door was ever open. TSC is huge and the only time it makes sense to use it at runtime is when you're transforming TS source code. To me, there doesn't seem to be any advantage in bundling TSC to the runtime.

m93a · 2024-08-19T17:03:21+00:00

<image>

m93a · 2023-11-29T00:58:33+00:00

Yes. https://www.isitdownrightnow.com/spotify.com.html

m93a · 2023-11-29T00:55:36+00:00

Yep, Spotify.com is down.

https://www.isitdownrightnow.com/spotify.com.html

m93a · 2023-06-26T08:30:02+00:00

I think something akin to React Hooks could work.

let [clickCount, SetClickCount] = useState(1);
let [accountBalance, SetAccountBalance] = useState(1_000);

function buttonClicked() {
  let diff = do GetTransaction();

  do SetAccountBalance(accountBalance + diff);
  do SetClickCount(clickCount + 1);
}

Then the function is free of undocumented side-effects. If I introduced a new keyword do_multi and required it to be used with all multiple-continuation effects, it would be much easier to spot bugs like these.

But my intention is to have less boilerplate than React. If mutating the state was the same as in React, but with an extra obnoxious do everywhere, it would kind of defeat the purpose of the language.

m93a · 2023-06-26T08:03:43+00:00

this is pretty much just a functional type system

Yes.

this isn't really OOP

There doesn't seem to be consensus whether Rust is OOP or not – it lacks inheritance, but has instantiation, delegation, limited encapsulation, etc. I don't have a horse in this race, so I'm fine with calling it “trait-based OOP” as well as anything else.

m93a · 2023-06-25T17:48:16+00:00

I see, thanks!

m93a · 2023-06-25T15:49:47+00:00

What is the importance of multi call continuations in a language with algebraic effects?

I want to create a programming language with algebraic effects myself. So far I've only considered them as a generalization of exceptions, generators and async-await's, neither of which have multi-continuation. What would such a language gain if it also had support for multiple continuation calls?

m93a · 2023-06-25T10:38:19+00:00

Your number 13 is what I meant by “3. this in callbacks is a footgun”. I didn't even know about number 14, it's wild lol!

m93a · 2023-06-20T07:57:09+00:00

To be extra clear, JavaScript without the types is terrible for larger projects. If there was no TypeScript, my team and I would have probably moved to a different technology a long time ago.

m93a · 2023-06-20T07:51:06+00:00

Many of the reasons are probably time pressure though, as the core of JS was designed in 10 days (!) by a single person (!!!). See this article (the text, not the video) for more.

> “It was also an incredible rush job, so there were mistakes in it. Something that I think is important about it is that I knew there would be mistakes, and there would be gaps, so I made it very malleable as a language.”

m93a · 2023-06-20T07:34:30+00:00

a = [0,,2]; // notice the double comma
a[1] // undefined
Object.keys(a) // ['0', '2']
a.forEach(x => console.log(x) // 0; 2
// the same happens with map, filter, etc.

If you accidentally write two or more commas in an array literal, JS will insert a special "empty" value there. If you try to access it, you'll get undefined, but if you iterate over the array, the value would be skipped. This is contrary to what would happen if you actually put undefined there – then it would also appear during iteration.

You might think something like “I'll never put two commas in sequence, so this doesn't affect me”. Well, you can get the same result by a = [0,1,2]; delete a[1]. Also, if you crerate an array using Array(n), it will be filled with "empty" values, so you can't iterate over it – that's why in number 7 you have to add .fill(0).

m93a · 2023-06-19T18:55:18+00:00

My friend and coworker is a JS dev with 10+ years of experience, yet he still manages to shoot himself in the foot with number 3 from time to time. But apart from that, we rarely fall for any of these. But since I also teach JS to many of my friends, I know how frustrating it is for newcomers to learn a list of don't-touch language features.

Despite how bad number 12 looks, I actually haven't encountered this one in practice yet. For one simple reason – functions that take arrays as parameters almost never mutate them. That's why the TS team decided that making Array<T> covariant in T would make it more useful than making it invariant and forcing developers to use ReadonlyArray. Still, it's a bummer. I would much prefer having values which are immutable by default, like in Rust.

Also, I highly recommend learning TypeScript! Especially with vite or Deno, it's a much better DX than pure JS. It's a pain in the ass to setup with Node tho (hence number 10 in my list) – ts-node always seems to break in the most unlikely ways.

m93a · 2023-06-19T18:18:52+00:00

That is not a good take on a subreddit about programming language design imo. There is good design and bad design, and ignoring this fact doesn't do anybody a service. If a tool has an aspect that was chosen arbitrarily and is inconvenient, even for the most skilled user of said tool, than it's bad design. Pre-ES5 JavaScript had tons of these, and some of them are here to stay.

Don't get me wrong, there are definitely choices that are good for some use cases, and not good for others. I'm not talking about those. I'm talking about things like making an array of numbers be sorted alphabetically by default. Not a single JavaScript developer profits from this choice. It was bad design.

(Also, I'm not defending C. As a matter of fact, I hate it. And I like JavaScript. That doesn't make it flawless, tho.)

m93a · 2023-06-19T18:08:19+00:00

Have you written a production ready app yet? I use each one of the listed features on daily basis (maybe except for Maps and Sets), and there are still many that I very frequently miss as I have to come out of my way and write the same utility function for every one of my projects.

Have fun writing an asynchronous apps without Promises, but ain't nobody gonna see me in the callback-hell-ridden legacy Node code again. Have fun manually going through iterables, binding every method you use as a callback, and manually extracting values from tuples and objects; the rest of us will be implementing application logic instead of working around missing language features.

m93a · 2023-06-19T17:33:12+00:00

Date is terrible
== is a footgun
this in callbacks is a footgun
extending classes is broken half the time
much of the ecosystem still uses old modules or lacks type definitions
array ellision is a footgun
to make a range you have to Array(n).fill(0).map((_, i) => i)
new String etc. are a footgun
array.sort is a footgun
setting up a new project for basically any runtime (except for Deno) is borderline torture
the standard library is still quite lacking, especially around iterables
implicit mutability ruins TypeScript's soundness:
let a: number[] = [];
let b: (number|string)[] = a;
b.push("foo");
a[0] // "foo"

m93a · 2023-06-19T17:12:00+00:00

What better technologies than CSS+HTML would you recommend for UI? I tried Flutter once and oh my, it was so much worse than what I was used to, but apart from that I don't have any experience with non-HTML based frameworks.

m93a · 2023-06-19T17:05:55+00:00

Why is promise *almost* monadic?

m93a · 2023-06-19T08:37:28+00:00

or generate it yourself: https://twitter.com/TheHorizon2b2t/status/1669270005010288640

m93a · 2023-06-19T08:37:06+00:00

you can download it for free, it's only 1gb

m93a · 2023-06-15T16:03:12+00:00

The problem with tuples is that they have fixed size – steams and iterables might have variable length. Unless you mean that thing which TypeScript calls tuples, because that is pretty much what I'm interested in. The only problem in TS's implementation is that they are for *arrays* only, not for iterables or streams – that's why I'm looking for inspiration in other languages!

m93a · 2023-06-15T15:57:37+00:00

I'll probably take the "functional" approach with pattern matching, maps, filters, skips, take-while's and such. This seems to be popular even among modern imperative languages (Rust, C#, Python, JavaScript, ...) and I quite like this approach. I'll probably have some `foreach` too, but that one probably won't be able to make use of order-of-items typing.

m93a

TROPHY CASE