Around 2020, I switched into the startup space and quickly picked up TypeScript since that's "what the kids use". It wasn't without struggles, but once I wrapped my head around TypeScript as "shapes for JavaScript", it clicked.

At the time, the startup was undertaking a new product built on Nest.js[0] which looked awfully similar to ASP.NET web APIs which had the benefit of being much more mature, complete, and with one of the best ORMs (EF Core). I suggested it to the team and was a bit shocked by the pushback.

It ultimately inspired me to do a bunch of writing [1][2] on just how similar these two languages are and how they've converged on syntax (no doubt owing to Anders at the helm). Of course, they ultimately still have quite a bit of a gap, but for teams that are working in TS and finding that they are outgrowing it, C# is a very natural choice.

I left that startup after a short stint, but boomeranged almost 3 years later. Company went from seed to series C in that time. End of last year, we started the migration from TypeScript on the backend to C# on the backend and haven't looked back. The toolchain is far simpler and stable, the "default" ORM is far more flexible and powerful, the more rigorous type chain seems more conducive for agent-driven coding. Team adapted relatively quickly within ~4 weeks.

[0] https://nestjs.com/

[1] https://typescript-is-like-csharp.chrlschn.dev/

[2] https://itnext.io/getting-functional-with-c-6c74bf279616

What's even more interesting is that Microsoft and Google were part of TC-39 at the time, and were the main opponents of ES4. While they had some rightful reasons to take this position, there's no way ES4 hasn't shaped TS in the end. Perhaps the lack of mention of any of this is due to that TypeScript might have been handed to Anders' team after the project vision and original design have developed (in the video, it is introduced as a continuation of "SharpScript"), but the interview still left me rather insatiated.

The part about veering constantly to navigate the maze of internal politics is fascinating. The compromises he had to make, like not being able to put in on Github initially. The easy victories, like making TypeScript open source.

The long road to success. The obligatory advice for people writing new programming languages (Hint: Mostly, don't.). His opinion about creating a new language for AI (I agree with his insight, but still think it is possible).

Overall, well worth watching.

It infers types. If I do

    const data = [
      { name: 'bob', age: 35, state: 'CA' },
      { name: 'jill', age: 37, state: 'MA' },
      { name: 'sam', age: 23, state: 'NY' },
    ];

Further, if I use any field, example

    const avg = data.reduce((acc, { age }) => acc + age, 0) / data.length;

Further, if I add `as const` at the end of data, then it will know 'state' can only be one of `CA`, `MA`, `NY` and complain if I try to check it against any other value. Maybe in this case 'state' was a bad choice of example but there are plenty of cases where this has been super useful both for type safety and for code completion.

There's insane levels of depth you can build with this.

Another simple example

    const kColors = {
      red: '#FF0000',
      green: '#00FF00',
      blue: '#0000FF',
    } as const;

    function keysOf<T extends string>(obj: { [k in T]?: unknown }): readonly T[] {
      return Object.keys(obj) as unknown[] as T[];
    }

    type Color = keyof typeof kColors;
    const kAllColors = keysOf(kColors);

In most other languages I've used I'd have to first declare a separate enum for the type, then associate each of the "keys" with a value. Then separately make an array of enum values by hand for iteration, easy to get out of sync with the enum declaration.

A MINIMAL memory safe language. The less it has the better.

Rust without the crazy town complexity.

The distilled wisdom from C# and Delphi and TypeScript.

A programming language that has less instead of more.

That last one was a mistake, see https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I just hope they will not overengineer and ruin it moving forward

I was there since '00.

It all started with Macromedia and their animation tool. They had an idea to add simple scripting so you add commands like "stop" or "gotoAndPlay(n)" on your animation timeline. For whatever reason they chose to use EcmaScript (aka JS).

Soon after it turned out that people were doing actual programming and shortly after in 2003 they came up with updated version called ActionScript 2.0 that added all OOP features from Java. This became the EcmaScript 4 draft.

If you ever wondered why JS has reserved keywords like "abstract", "protected" or "interface" this is why.

What's funny is that by that time the underlying engine was still working on the old ES3 so when you compiled your app your code was transpiled in exact same way TS is transpiled into JS today.

We had MXML, which was XML for laying out your controllers and classes like we do today with React and web components.

We had Alchemy that allowed you to compile C directly into Flash bytecode - exactly what emscripten is doing. And there was even a way to write assembler directly if you were brave enough.

Around 2008 there was even a thing called RedTamarin which was... command line runtime for ActionScript, just like NodeJS.

And then Apple came, Flash was gone, and with it all these things.

All of these things were erased from memory, and for the next 10 years community was slowly reinventing the wheel.