[jodrellblank]

> "given that C# was famously created by the guy writing the blog post"

What is this logic? "You worked on C# years ago so you must use C# for everything"?

"You must dictate C# to every team you lead forever, no matter what skills they have"?

"You must uphold a dogma that C# is the best language for everything, because you touched it last"?

Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those? Because there is no logic; the person who created hammers doesn't have to use hammers to solve every problem.

[uticus]

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course).

So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages.

If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?

[_bin_]

funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.

[nindalf]

Could you give some examples of both? Also, why did they choose to do this?

[_bin_]

Sure. Mazda’s CX-3/5/9 in the aughts and early teens often had licensed Ford engines. The current Ford Tourneo Connect has a wholly VW-manufactured engine.

It’s probably most common when an automaker introduces a new make and wants to save time and capital on developing and getting into production a new engine.

[sellmesoap]

The last model of ford ranger and Mazda B series light pickup trucks were mostly the same except for the badges.

The Toyota matrix and Pontiac vibe used a lot of the same parts shared an engine and drivetrains if I'm not mistaken.

[kcrwfrd_]

Toyota 86 and Subaru BRZ are basically the same car. The car was designed by Toyota while Subaru supplied the engine. Just one example.

[sellmesoap]

I think Toyota also owns a significant amount of Subaru, probably other mfgs. as well, Toyota is the 600lb gorilla of the car industry.

[jodrellblank]

> "So it's not just that the lead architect of C# is involved in the TypeScript changes."

Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is:

https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - "I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And then when he and I had a little side project with others to do TypeScript, he stayed over there. And I got to take over as lead designer C#. So for the last, I don’t know, nearly a decade, that’s been my job at Microsoft to, to take care of the evolution of the C# programming language"

Years later, "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird; he's a person with a job, not a religious cult leader.

> "If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?"

Like these? https://www.slashgear.com/1642034/fords-powered-by-non-ford-...

[cxr]

> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird

It's also not what anyone said.

> It's best not to use quotation marks to make it look like you're quoting someone when you're not. <https://news.ycombinator.com/item?id=21643562>

[jodrellblank]

Why is that "best" ?

> "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu...

I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?" has the implicit framing "it should be C# by default and you have to justify why not" and calling out that bias to show it to be unreasonable is the intent.

[uticus]

> Like these...

Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course).

I chose the analogy carefully.

[jodrellblank]

The analogy missed because I am not American or a car enthusiast.

[andy81]

F# isn't in the running for third either.

Maybe top ten behind MSSQL, Powershell, Excel Formulae, DAX etc.

[sterlind]

hey, there are dozens of us F# users! dozens!

I do love F#, but its compiler is a rusty set of monkey bars. It's somehow single pass, meaning the type checker will struggle if you don't reorder certain expressions - but also dog slow, especially for `inline` definitions (which work more like templates or hygienic macros than .net generics, and are far more powerful.) File order matters, bafflingly! Newer .net features like spans and ref structs are missing with no clear path to implementation. Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors. F# is built around immutability but there's no integration with the modern .net immutable collections.

It's clearly languishing and being kept alive by a skeleton crew, which is sad, because it deserves better, but I've used research prototypes less clunky than what ought to be a flagship.

[throw234234234]

There's more than a dozen - I should know. I've seen quite a few large systems built in it. Most of the time however it isn't well advertised (finance, insurance, etc).

- I don't think the compiler is actually that bad, and yes - inline definitions I think once you are going on the "templating route" are going to be slower. Spans and ref structs are there - I think the design of them is more intuitive actually - the C# "ref struct" at first glance sounds like an oxymoron to me.

- modern .net immutable collections - in testing these are significantly slower than some of the F# options especially when you go away from the standard lib and use some of the other collection libraries. The algorithms within the C# immutable libs were not as optimal for some common collection types. They didn't feel modern last time I used them and I was forced to switch to the F# ones and/or others in the F# ecosystem to get the performance I needed. Immutable code felt MUCH more idiomatic with F#.

- "Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors" - happened with init fields for me; can't recall another time.

Don't mind the file order bit - I thought OCAml and a few other languages also do this. Apps still scale OK, and when I was coding in it got me out of a few spaghetti code issues as the code scaled up to about the 500,000+ LOC mark.

However I do agree with you on it being kept alive by skeleton crew - I think the creators and tooling staff have moved on to the next big thing (AI and specifically Github Copilot). Which the way things are moving will raise some interesting questions about all coding languages in general potentially.

[debugnik]

> Newer .net features like spans and ref structs are missing with no clear path to implementation

Huh? They're already implemented! It took years and they've still got some rough edges, yes, but they've been implemented for a few years now.

Agreed with the rest, though. As much as I love working with F#, I've jumped ship.

[jay_kyburz]

It's a bad look for both C# and TypeScript. Anybody starting a new code base now would be looking for ways to avoid both and jump right to Go.

[sethaurus]

I'm struggling to understand how this is a bad look for Typescript. Do you mean that the specific choice of Go reflects poorly on Typescript, or just the decision to rewrite the compiler in a different non-TS language?

If it's the latter, I think the pitch of TS remains the same — it's a better way of writing JS, not the best language for all contexts.

[jay_kyburz]

I think a lot of folks downplay the performance costs for the convenience of a shared code-base between the front and backend.

If the TS team is getting a 10x improvement moving from TS to Go, you might imagine you could save about 10x on your server cpu. Or that your backend would be 10x more responsive.

If you have dedicated team for front and back anyhow, is a 10x slow down really worth a shared codebase?

[bdangubic]

if I had to use Go I’d change my career and go do some gardening :)

[bbkane]

I actually really enjoy Go. Sure it has a type system I wish was more powerful with lots of weird corners ( https://100go.co/ ), but it also has REALLY GOOD tooling- lots of nice libraries, the compiler is fast, the editor tooling is rock solid, it's easy to add linters to warn you about many issues (golangci-lint), and releasing binaries and updating package repositories is super nice (Goreleaser).

[ricardobeat]

I'd probably have said the same 5 years ago, it's surprising how easy you change sides once you actually use it in a team.

[bdangubic]

I was mostly joking… some of the most amazing shit code-wise I have seen in “non-mainstream” languages (fortran leads the way here)

[keyle]

I had to, and I do think a lot about gardening these days...

[zeroc8]

I like Anders'answer there. "But you can achieve pretty great things with it".

[saturn_vk]

Because it's so easy that you'd have a lot more time for gardening?

[moogly]

If they're writing (actually porting) a _compiler_, perhaps.

[osigurdson]

Go doesn't run in the browser however (except WASM but that is different).

[Hello71]

> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?

as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.