Live data from Hacker News

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

youtube.com

121–130 of 162 posts

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

#121
post #43

Earlier quoted context omitted.

> They did not do a lot of mistakes in the 25+ years If my memory serves, .NET and WinFS were the two major forces that sunk Longhorn, and both have been given their walking papers after the reset [1]. .NET and C# have grown to be mature and well-engineered projects, but the road there was certainly not without bumps. It's just that a lot of the bad parts haven't spilled outside of Microsoft, thankfully. [1] https://…

.NET was already a going concern before Longhorn even started. What sank Longhorn was the fact that writing an OS from scratch is hard and maintaining compatibility with existing OSes in the process is even harder, especially when you're adopting a completely new architecture. Longhorn would have been a microkernel running 100% on the .NET runtime, mainline Windows is a monolithic kernel written in C++. I don't know…

No, Longhorn was neither a microkernel nor was the kernel rewritten in .NET.

Source: I was there.

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

#122

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 l…

I assume the startup wasn't also leveraging typescript heavily on the frontend, that tends to shift the weight in its favor. Having one set of tools to use across everything, being able to share logic and types without needing to go through lossy translation layers, and giving (especially small) teams better flexibility to move people around is a huge benefit.

We are using TS on the FE with React.

But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js).

So there was no benefit to using TS on both ends; only pain on the BE.

If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language:

    - Easy for a TS team to adopt; similar core semantics like `async/await`, exception handling, etc.
    - Flexible and pluggable OpenAPI spec generation for edge cases and advanced scenarios
    - Excellent ORM to improve productivity around CRUD
    - Good tooling
    - Extensive docs, platform maturity, but modern language features
C# meets all of those in ways that no other language and platform does.

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

#123

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 l…

I can't say for sure because I don't know the full situation, but I've heard a similar story a few times and IMNSHO looking at it as "they made the wrong choice initially" is off because it assumes that a C# team could have delivered the initial version in the timeline required to get to the the next level of project. If they had a team that knows nest and can iterate fast with it that's the perfect choice. I've work…

    > ...because it assumes that a C# team could have delivered the initial version in the timeline required to get to the the next level of project.
I linked the Nest.js project because you can see how similar these two are[0] with Nest.js leaning into the OOP aspects of TS at the very core. Controllers and services are classes in Nest.js, for example. It uses a somehow more complicated DI system than ASP.NET. It is Spring Boot or ASP.NET, but without the maturity, performance, and ergonomics.

The team had developers that had done C# before and later hires also included former C# developers.

TS itself was new for the team at the time and several mistakes were made along the way resulting in a "dual-ORM" situation (Prisma + Drizzle; both with their faults) that ends up sapping a lot of productivity (one of the drivers to move to C#).

[0] https://typescript-is-like-csharp.chrlschn.dev/pages/interme...

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

#124
post #94

Earlier quoted context omitted.

I can't say for sure because I don't know the full situation, but I've heard a similar story a few times and IMNSHO looking at it as "they made the wrong choice initially" is off because it assumes that a C# team could have delivered the initial version in the timeline required to get to the the next level of project. If they had a team that knows nest and can iterate fast with it that's the perfect choice. I've work…

Same experience here. C# might have superior tooling, performance, whatever but the OOP baggage is too heavy. In theory you can write something else than a giant over-complicated, over-abstracted pile of OOP nonsense in C#, but every team I've seen has .

You can write very functional C#. Our codebase is a mix with some aspects being functional (`ErrorOr`[0] being a big part of it as well as `OneOf`[1]) and OOP. Our core, common services all return `ErrorOr` to allow fluent call chaining at the top of the stack (controllers).

Modern C# features like `switch` expressions[2] (not `switch-case`) and pattern matching mean that it is possible to write very terse, expressive code. Extension members and methods[3] go a long way as well by making the builder pattern easier to implement.

Overall, it's up to the team to make use of the tools provided by the C# team. You can write C# in a very OOP heavy way (as is possible with TS in the case of Nest.js); you can also write in in a very functional way given many of the functional features adopted from F# over the years. It's up to the team.

[0] https://github.com/amantinband/error-or

[1] https://github.com/mcintyre321/OneOf

[2] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

[3] https://typescript-is-like-csharp.chrlschn.dev/pages/interme...

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

#125

Earlier quoted context omitted.

All non-generic container classes and nullable reference types.

> nullable reference types. What would you suggest instead? I quite like the nullable reference types, but I do know many get annoyed. My brain is often a scurry of squirrels, so I grew to become thankful for the nullable refs overtime.

I don't mind NRT but I hate dealing with C# projects that haven't set Enable in their csproj. It's not perfect because I know at runtime it can still be nullable but it's nice when the compiler does most of the checks for you.

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

#126

The real history of C# is that it is a rip off of Java. Anders / Microsoft understandably doesn't want to acknowledge that, but the rest of us can. C# today has diverged from Java, but the original release was Java with a few features added, such as properties, delegates, structs and unchecked exceptions. That last one was a mistake, see https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I recently wrote a project in C# 2.0 and i actually had the opposite conclusion; the inspiration from Java is clearly there but even by 2.0 it had diverged pretty meaningfully

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

#127

The real history of C# is that it is a rip off of Java. Anders / Microsoft understandably doesn't want to acknowledge that, but the rest of us can. C# today has diverged from Java, but the original release was Java with a few features added, such as properties, delegates, structs and unchecked exceptions. That last one was a mistake, see https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I recently wrote a project in C# 2.0 and i actually had the opposite conclusion; the inspiration from Java is clearly there but even by 2.0 it had diverged pretty meaningfully

Yes the languages have diverged, especially the ecosystems. For big data projects Java/JVM languages are preferred. For many open source projects too, Java is preferred because C# was late to the OSS party. But for many enterprise web applications ASP.NET works well.

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

#128

Earlier quoted context omitted.

All non-generic container classes and nullable reference types.

> nullable reference types. What would you suggest instead? I quite like the nullable reference types, but I do know many get annoyed. My brain is often a scurry of squirrels, so I grew to become thankful for the nullable refs overtime.

The compiler now mostly solves this now but the abstraction is a little leaky.

I heavily use nullable types but I always want them to be declared nullable.

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

#129

The real history of C# is that it is a rip off of Java. Anders / Microsoft understandably doesn't want to acknowledge that, but the rest of us can. C# today has diverged from Java, but the original release was Java with a few features added, such as properties, delegates, structs and unchecked exceptions. That last one was a mistake, see https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I was around in that era and yes when C# came out it was very obvious that Microsoft had been 'inspired' by the Java syntax ... Java had been the buzzword for the 5 years or so beforehand, like the only language that anyone talked about, so when Microsoft came up with C# it was glaringly obvious where they got the idea from.

On the other hand Java came with the VM ("write once run anywhere" as they used to say) but C# turned that inside out with the Common Langauge Runtime, so you had various languages like C# and VB.Net that compiled to the same bytecode.

The other innovation with Java back in the day was that it came with a huge library/framework of classes that did most of the stuff you would need to do. Similarly Microsoft's .NET library was a copy of that idea, although the frameworks themselves were pretty different.

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

#130
post #43
post #35

Earlier quoted context omitted.

As a long term observer: definitely not a goal. But you have to be clear here: JavaScript and C# both are OO languages, both are having origins stories in Java/C++, both are facing the same niche (system development), same challenges (processor counts, ...) and so on. And then, you put teams on it which look left and right when they face a problem and then you wonder that they reuse what they like? C# language team i…

> They did not do a lot of mistakes in the 25+ years If my memory serves, .NET and WinFS were the two major forces that sunk Longhorn, and both have been given their walking papers after the reset [1]. .NET and C# have grown to be mature and well-engineered projects, but the road there was certainly not without bumps. It's just that a lot of the bad parts haven't spilled outside of Microsoft, thankfully. [1] https://…

The article is presenting some stuff mixed up. Had nothing to do with the language or the framework. WinFS was a database product. Over engineered and abstract.

.NET and C# were researched a lot for operating system usage (Midori, Singularity) but that was after Longhorn.

The operating system group UI toolkits was a further problem and they pivoted there dozen of times in the years. Particular for a C++ based os group.

But the death of longhorn was ultimately about the security restart of Bill Gates

Post reply on HN