5 ms·

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

by rixtox 8mo ago

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.

tester756 8mo ago
It sounds like conspiracy theory that they design TS/JS to convert from C# easier, huh. The truth is that C# is probably the best designed mainstream language out there. C# was known as a language with lowest amount of WTF per LoC
froh 8mo ago
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 ...
- oaiey 8mo ago
  Spot on.
- ptx 8mo ago
  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 deliberately hobbles features to benefit Microsoft [5]. [1] https://peps.python.org/pep-0013/ https://peps.python.org/pep-0013/ [2] https://dotnetfoundation.org/about/policies/.net-foundation-bylaws https://dotnetfoundation.org/about/policies/.net-foundation-... [3] https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md [4] https://github.com/dotnet/sdk/issues/6145 https://github.com/dotnet/sdk/issues/6145 [5] https://github.com/dotnet/sdk/issues/22247 https://github.com/dotnet/sdk/issues/22247
  - no_wizard 8mo ago
    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-watch#hot-reload https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-w...
  - WorldMaker 8mo ago
    The complaint above was that JS was becoming too much like C#, so the steering committee of .NET isn't the one of the original concern. (Also, as pointed out, that "deliberate hobbling" case was litigated in the public square on HN at the time and then revised and "unhobbled" after the outcry.) As far as the other direction, JS has a somewhat similar (but rather more complex) situation to Python with its steering committee being Ecma International's TC39 (Technical Committee 39). Ecma International has similar By-Laws and Rules designed to manage conflict of interest and too much power consolidate in a single employer of committee members. Ecma is maybe even a little "stricter" than Python because its rules consider the companies themselves to be the members, and companies only get one vote no matter how many employees interact with the process. https://ecma-international.org/policies/by-laws/ https://ecma-international.org/policies/by-laws/ https://ecma-international.org/policies/rules/ https://ecma-international.org/policies/rules/
steve1977 8mo ago
Well, for one, benefiting Microsoft's ecosystem does not imply being detrimental to other ecosystems per se. Furthermore, couldn't the convergence of TypeScript towards C# be simply a result of shared goals and values of the two languages, especially considering they have the same principal designer?
oaiey 8mo ago
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 is also really good. They did not do a lot of mistakes in the 25+ years. They are a very valid source of OO and OO-hybrid concepts. It is not only TS/JS but also Java and C++ who often look to C#. The story was not to transform C# code to JS but to use C# to write the code in the first place and transpile it. Not for the sake of having .NET usage but for the sake of having a good IDE.
- m132 8mo ago
  > 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://www.theregister.com/2005/05/26/dotnet_longhorn/ https://www.theregister.com/2005/05/26/dotnet_longhorn/
  - Sammi 8mo ago
    Are we mixing the language and the runtime here? C# the language seems weirdly free of weirdness and footguns.
    - jayd16 8mo ago
      Not only that, they went as deep as mixing in project issues with language design. A massive rewrite mixed with massive feature changes is always a tricky thing no matter the language.
  - moron4hire 8mo ago
    .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 how it would have ever worked, whether .NET was "perfect" or not.
epolanski 8mo ago
C# is inherently OOP oriented and it's type system works completely differently.
pmkary 8mo ago
Not at all. Before the use of TypeScript exploded, they had two features brought into it from C# which were namespaces and enums (both of which are amazingly good features. For the first one, no one knew what was the right choice back then. We had almost a dozen different module systems and TypeScript had gone their way to support all of them and namespaces were their own solution to the mess (remember they were trying to solve their own problems at first, it wasn't to dominate anything). I personally used namespaces and I could have only the TypeScript compiler running and producing a single JS file for rapid development without the burden of --- then very slow --- webpack. And for enums, using strings as enums was not a very efficient idea. I think JavaScript introduced Symbols for locked/hidden properties but also meant to use them as enums. It never worked either and then the sum type, union type feature of TypeScript made the whole community to keep using strings as enums. This is still a very bad idea, it is not ergonomic, it is prone to many problems, and very inefficient to compare strings instead of integers. But hey TypeScript tried to fix the problem and almost everyone rejected it. And so enum is now discontinued. Rest of the changes to TypeScript came from almost any other language but C#, probably the biggest changes ever to happen to JavaScript came directly from CoffeeScript. And then I personally saw how each of these new changes --- one by one --- arrived at C#. For what I have seen firsthand by reading the TC39 proposals, each feature came from a different community and different programming languages, (think about null operators !/?, the nullish coalescing ??, the incoming pipes, fat arrows and lambdas, mixings) as JavaScript is the only language everyone has to use, and it has benefited everyone to have a language that has all the great things from all other languages.

by rixtox 8mo ago

tester756 8mo ago

It sounds like conspiracy theory that they design TS/JS to convert from C# easier, huh. The truth is that C# is probably the best designed mainstream language out there. C# was known as a language with lowest amount of WTF per LoC

froh 8mo ago

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

oaiey 8mo ago
Spot on.
ptx 8mo ago
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 deliberately hobbles features to benefit Microsoft [5]. [1] https://peps.python.org/pep-0013/ https://peps.python.org/pep-0013/ [2] https://dotnetfoundation.org/about/policies/.net-foundation-bylaws https://dotnetfoundation.org/about/policies/.net-foundation-... [3] https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md [4] https://github.com/dotnet/sdk/issues/6145 https://github.com/dotnet/sdk/issues/6145 [5] https://github.com/dotnet/sdk/issues/22247 https://github.com/dotnet/sdk/issues/22247
- no_wizard 8mo ago
  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-watch#hot-reload https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-w...
- WorldMaker 8mo ago
  The complaint above was that JS was becoming too much like C#, so the steering committee of .NET isn't the one of the original concern. (Also, as pointed out, that "deliberate hobbling" case was litigated in the public square on HN at the time and then revised and "unhobbled" after the outcry.) As far as the other direction, JS has a somewhat similar (but rather more complex) situation to Python with its steering committee being Ecma International's TC39 (Technical Committee 39). Ecma International has similar By-Laws and Rules designed to manage conflict of interest and too much power consolidate in a single employer of committee members. Ecma is maybe even a little "stricter" than Python because its rules consider the companies themselves to be the members, and companies only get one vote no matter how many employees interact with the process. https://ecma-international.org/policies/by-laws/ https://ecma-international.org/policies/by-laws/ https://ecma-international.org/policies/rules/ https://ecma-international.org/policies/rules/

steve1977 8mo ago

Well, for one, benefiting Microsoft's ecosystem does not imply being detrimental to other ecosystems per se. Furthermore, couldn't the convergence of TypeScript towards C# be simply a result of shared goals and values of the two languages, especially considering they have the same principal designer?

oaiey 8mo ago

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 is also really good. They did not do a lot of mistakes in the 25+ years. They are a very valid source of OO and OO-hybrid concepts. It is not only TS/JS but also Java and C++ who often look to C#. The story was not to transform C# code to JS but to use C# to write the code in the first place and transpile it. Not for the sake of having .NET usage but for the sake of having a good IDE.

m132 8mo ago
> 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://www.theregister.com/2005/05/26/dotnet_longhorn/ https://www.theregister.com/2005/05/26/dotnet_longhorn/
- Sammi 8mo ago
  Are we mixing the language and the runtime here? C# the language seems weirdly free of weirdness and footguns.
  - jayd16 8mo ago
    Not only that, they went as deep as mixing in project issues with language design. A massive rewrite mixed with massive feature changes is always a tricky thing no matter the language.
- moron4hire 8mo ago
  .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 how it would have ever worked, whether .NET was "perfect" or not.

epolanski 8mo ago

C# is inherently OOP oriented and it's type system works completely differently.

pmkary 8mo ago

Not at all. Before the use of TypeScript exploded, they had two features brought into it from C# which were namespaces and enums (both of which are amazingly good features. For the first one, no one knew what was the right choice back then. We had almost a dozen different module systems and TypeScript had gone their way to support all of them and namespaces were their own solution to the mess (remember they were trying to solve their own problems at first, it wasn't to dominate anything). I personally used namespaces and I could have only the TypeScript compiler running and producing a single JS file for rapid development without the burden of --- then very slow --- webpack. And for enums, using strings as enums was not a very efficient idea. I think JavaScript introduced Symbols for locked/hidden properties but also meant to use them as enums. It never worked either and then the sum type, union type feature of TypeScript made the whole community to keep using strings as enums. This is still a very bad idea, it is not ergonomic, it is prone to many problems, and very inefficient to compare strings instead of integers. But hey TypeScript tried to fix the problem and almost everyone rejected it. And so enum is now discontinued. Rest of the changes to TypeScript came from almost any other language but C#, probably the biggest changes ever to happen to JavaScript came directly from CoffeeScript. And then I personally saw how each of these new changes --- one by one --- arrived at C#. For what I have seen firsthand by reading the TC39 proposals, each feature came from a different community and different programming languages, (think about null operators !/?, the nullish coalescing ??, the incoming pipes, fat arrows and lambdas, mixings) as JavaScript is the only language everyone has to use, and it has benefited everyone to have a language that has all the great things from all other languages.