Live data from Hacker News

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

youtube.com

131–140 of 162 posts

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

#131

Earlier quoted context omitted.

.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.

I think he confuses longhorn with Singularity research project.

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

#132
post #52
post #24

Earlier quoted context omitted.

that's the "evil MS" perspective The sequence of turbo pascal / delphi / c# / typescript which brought us LSP as a sidekick (!) IMHO has benefitted the whole industry at least as much as "transpile c# to ecma script via typescript" . no. much much much more. I do not see a problem with MS also having an internal use case . you know I wouldn't stop using python "because" Guido now works at MS ...

Python has an elected steering council and core team. The governance process explicitly tries to avoid conflict of interest by disallowing more than two steering council members working for the same employer. See PEP 13 [1]. By contrast, .NET is controlled by Microsoft (with veto over board decisions [2] and code changes [3]), integrates Microsoft's telemetry to send your data to Microsoft by default [4] and delibera…

According to the docs, .NET 10 has hot reload via the cli, unless I'm misunderstanding something: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-w...

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

#133

Earlier quoted context omitted.

>We need Anders to make one final language. I do feel like there is a gap for a modern compiled, functional and garbage collected language. Go isn't it because it lacks the functional constructs. C# and Java aren't it because they depend on a VM. Rust isn't it because of its difficult memory management. Swift isn't it because it is so tied to Apple and their platforms.

C# doesn't depend on a VM these days when it is AOT compiled. Same for Java, though C# is rather more user friendly in how it goes about it.

> C# doesn't depend on a VM these days when it is AOT compiled

Maybe I’m being pedantic, but this is an oxymoron. Also the premise is incorrect. It’s not like the VM is gone. Merely baked into the code at compile time. It compiles IL to native code. Same for IL2CPP. The VM is still there.

The term “virtual machine” is confusing. I think you meant to say JIT compiler :-)

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

#134

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…

Hmmm. I have a different take there: when you are young and wild, you achieve stuff because you think later and instantly produce code. When you turn older, you do it the other way leading to your example.

In the early 2000s I have been in a startup and we delivered rapidly in C# as we did in PHP. We just coded the shit.

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

#135

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…

What you are describing is structural types. It is indeed a mystery that these are so under used, especially as they are a cornerstone of type theory. Structural types are so useful that they creep into most languages in some way. Even in Java, the Kingdom of the Nouns, where the rulers refused to merge a pair class, functions essentially take tuple arguments and these tuples don't have to be named and defined. You c…

OCaml has structural variants in the form of polymorphic variants. On the product side, OCaml has objects, first-class modules, labelled tuples (since OCaml 5.4) which are all a form of structural records, with different trade-off in term of ergonomics.

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

#136

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...

They're also sweeping VB.NET under the rug.

If I had to bet, I would guess VB.NET was the more popular .NET language at first. Everyone I know was converting all their ASP pages and VB apps to VB.NET.

I didn't switch from VB.NET to C# as my main language until 2021. (the 90s was all C/C++/Java for me)

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

#137

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.

I want something that will bring productivity of Delphi to Web. May be I am old now, but I could have built applications in a weekend in Access or Visual Basic that will take weeks now in latest web stack.

Eh. I admit I just use AI now when I want to quickly build a web app like that. I built a huge content management system in a couple of hours that way.

If you're talking Windows desktop apps like Delphi used to do, then Visual Studio WinForms is still just like that in 2026 and still getting updates.

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

#138
post #134

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…

Hmmm. I have a different take there: when you are young and wild, you achieve stuff because you think later and instantly produce code. When you turn older, you do it the other way leading to your example. In the early 2000s I have been in a startup and we delivered rapidly in C# as we did in PHP. We just coded the shit.

I think what you said is a healthy progression : write dumb code -> figure out it doesn't scale -> add a bunch of clever abstraction layers -> realize you fucked yourself when you're on call for 12 hours trying to fix a mess for a critical issue over the weekend x how many time it takes you to get it -> write dumb code and only abstract when necessary.

Problem is devs these days start from step two because we're teaching that in all sources - they never learned why it's done by doing step one - it's all theoretical example and dogma. Or they are solving problems from Google/Microsoft/etc. scale and they are a 5 people startup. But everyone wants to apply "lessons learned" by big tech.

And all this advice is usually coming from very questionable sources - tech influencers and book authors. People who spend more time talking about code than reading/writing it, and earn money by selling you on an idea. I remember opening uncle bobs repo once when I was learning clojure - the most unreadable scattered codebase I've seen in the language. I would never want to work with that guy - yet Clean Code was a staple for years. DDD preachers, Event driven gurus.

C# is the community where I've noticed this the most.

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

#139

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…

> the "default" ORM is far more flexible and powerful I have never used any ORM that is as capable. Entity Framework Core with Linq is what keeps me on .NET.

Because EF's default behavior implements Unit of Work, a LOT of the complex transactional spaghetti ended up disappearing when we switched.

This aspect of EF is highly underrated for complex entity graph mutations.

EF makes the 90% use case easy and the 10% case possible with very little pain. The interceptors, global conventions, and other extension points are an enabler of complex behaviors that are still transparent to most of the team.

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

#140
post #94

Earlier quoted context omitted.

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, expressiv…

That's a perfect example of making it overcomplicated, just in the FP direction.

C# uses exceptions for error handling. It has it's own control flow primitives. C# developers know how to work with it, everything else uses it. Why would I want to pull in a randos GH DSL and types to pretend I'm writing F# when I can just use F# that has first class support for this ?

Post reply on HN