logoalt Hacker News

The history of C# and TypeScript with Anders Hejlsberg [video]

105 pointsby doppplast Tuesday at 5:07 PM62 commentsview on HN

Comments

CharlieDigitaltoday at 2:13 PM

I started my career doing ~20 years of C# from pretty much the very beginning (JavaScript even before then!).

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

pdevrtoday at 9:54 AM

I watched this last week.

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.

m132today at 10:45 AM

Surprising to me that (in the context of TypeScript) ECMAScript 4, ActionScript, and Google Closure were not mentioned! Especially the first two; Macromedia/Adobe and Netscape/Mozilla have been working on baking TypeScript into JavaScript proper for a whole decade before HTML5, the mobile boom, and the associated problems have emerged. ES4/AS3 even had a nearly identical syntax.

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.

show 2 replies
socalgal2today at 8:51 AM

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it.

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' },
    ];
Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it.

Further, if I use any field, example

    const avg = data.reduce((acc, { age }) => acc + age, 0) / data.length;
It knows that `age` is a number. If I go change data and add an age that is not a number it will complain immediately. I didn't have to first define a type for data, it inferred it in a helpful way.

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);
Above, Color is effectively an enum of only 'red', 'green', 'blue'. I can use it in any function and it will complain if I don't pass something provably 'red', 'green', or 'blue'. kAllColors is something I can iterate over all colors. And I can safely index `kColors` only by a Color

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.

show 4 replies
theusustoday at 11:36 AM

Wasn’t he fired by MS?

andrewstuarttoday at 8:16 AM

We need Anders to make one final language.

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.

show 11 replies
rixtoxtoday at 9:33 AM

If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing ECMAScript. When they are pushing a language feature, they have an unspoken internal goal, and every choice they make is to make JS/TS look more like C#, and they are more likely to dismiss proposals that preventing them from deliverying that goal. There's likely a bit of conflict of interest there.

show 6 replies