5 ms·
What do you see as the issue being "controlled by microsoft"? What risk do you see here?
by CharlieDigital 3y ago
What do you see as the issue being "controlled by microsoft"?
What risk do you see here?
- AlecSchueler 3y agoThere was a good discussion just yesterday, "Why did Visual Basic die?" https://news.ycombinator.com/item?id=37470318 https://news.ycombinator.com/item?id=37470318 That might be a place to start looking. It basically comes down to:b they could take development in any direction and the community of users is powerless.
- jodrellblank 3y agoBut why can't you fork it and take it in the direction you want? The situation is literally no different from Python or Node or Ruby, the people running the most popular distribution could take it in a direction you don't like and the power you have (or the only option you have) is forking.
- AlecSchueler 3y agoThe development for a language like python happens entirely in public though, and is driven by consensus.
- jodrellblank 3y agohttps://github.com/dotnet/csharplang https://github.com/dotnet/csharplang - "The official repo for the design of the C# programming language" that's in public.
- AlecSchueler 3y agoInfront of the public, yes, but it says you need to be invited by someone from their team to participate yourself, compare that with the python process. There's a distinction to be made between doing something in public and something being done by the public.
- HelloNurse 3y agoFor .Net, there's an established pattern of careless deprecation that produced enough frameworks to date codebases like tree rings: - this year's correct way to access your database is... - this year's correct way to serve dynamic web pages is... - this year's correct way to make a Windows GUI is...
- eddythompson80 3y agoThis pattern exists in all languages. I’d argue more so in fragmented community driven projects/languages/tools. Except in the case of languages/tools like python, node, neovim etc. Everytime I touch one of these there is always a new better way of accessing DBs, making a web server, making a client side render, no a server side render, async library, configuration system, build system, runtime, GUI patterns etc.
- HelloNurse 3y agoThere is a marked difference between a third party releasing some new library and obtaining (to some extent, demanding) community mindshare, without taking away anything, and the official platform maintainer suddenly replacing practically mandatory parts of what is perceived as the standard library. Javascript churn is fast, .Net churn is deep.
- eddythompson80 3y agoThat's not really true. .NET Framework is still around. Even .NET core 3.x which is EOL a while ago, is still widely used with active stackoverflow and if you're loud enough with the .NET team at Microsoft they will help you there too. The only difference I see between both is that there is an authoritative opinion when it comes to .NET (Microsoft) while there is no authority figure when it comes to node/Javascript. Even the actual runtime, package manager, module resolution, build tools etc get forked and replaced but since there is no authority, everyone is like "lets wait and see who wins". While with a language like .NET (or Go for that matter) you know that whatever comes from Microsoft (or Google) is the authoritative answer and people are more likely to jump to it right away.
- edgyquant 3y agoWhy answer my question with the opposite question? What reasons do we have for specifically wanting to use a microsoft controlled language?
- CharlieDigital 3y agoI would just like to understand specific threats or issues with using C# as a language. I've used it for 20 years at this point without issue and the latest IEEE language survey shows that it remains one of the top languages[0]; I'm wondering if you have some insight into why .NET and C# are a bad choice for engineering teams that I've somehow overlooked in my 20 years of working with it. It sounds like your argument is "because Microsoft". If you are using VS Code, GitHub, or TypeScript -- well, all those are also controlled by Microsoft, aren't they? Microsoft is the biggest investor in OpenAI and in fact offers their own Azure labeled OpenAI -- are you going to give up on OpenAI because it's Microsoft controlled? React is controlled by Facebook. Go is controlled by Google. So what? Why use C#? - It's a very small step from TypeScript to C# if a team needs higher throughput on the backend[1][2] - `System.Linq` provides a superset of JS Array methods and is easy to map from one to the other. - It's performance is on par or superior to Go[3] and competitive with Rust[4] while being much easier to adopt because of the language similarity to JS and TS. - It is an object-functional hybrid language owing to its influence from F#[5]; discriminated unions are on the roadmap and available today with packages like Dunet and OneOf, it has pattern matching like Rust, extension methods provide flexibility in modelling, named tuples in C# 12 converge even more with TS, it supports destructuring record types and classes, it has immutable record types - Minimal APIs are very familiar for teams using Express but need more performance. I'd actually say that it's a bit simpler than Express on Node for common use cases since there's nothing to import when setting up minimal APIs since it's all first-party Microsoft. - Platform support for source generators are a revelation; it removes a lot of boilerplate code while actually improving performance over reflection. - Many of the things teams love about modern JS actually have influence from C#. Lambda expressions in JavaScript, `async/await`, and more. In fact, C# and JS/TS have been converging (see the linked repo). - It's relatively easy to write high throughput code in C# with support for both concurrency (Tasks + Channels) and high level abstractions for parallelism (Task Parallel Library) as well as full access to threading. - C# allows easy access to underlying low-level primitives; you can program with high level abstractions for productivity but still have access to call `unsafe` code if needed. - EF Core is possibly the best ORM on the market right now in terms of performance, ease of use, maturity, and database engine support. - A benefit of a language and runtime backed by Microsoft and used in the enterprise is that security issues get addressed by a team of professional engineers; you don't see the same types of security issues that pop up in the Node/NPM ecosystem. - This is a big boon particularly because of the broad standard libraries and first-party libraries for many use cases. Rather than importing unknown dependencies for common use cases, you end up with a baseline of professionally maintained, OSS code. - GitHub's State of the Octoverse report in 2020[6] showed that C# had the least Dependabot alerts and has the least transitive dependencies (less prone to security issues via package managers). - As a general purpose language, it can be used in many domains from desktop to devices to web to gaming (both Godot and Unity; RyujinX). - It's also quite mature and stable while languages like Rust are still ironing out async and Go just released generics. C# has been there; done that. My personal opinion is that C# is the language that most teams want but don't know enough about it or have a bad taste from the .NET Framework days. While the runtime is more complex than Node, the language is very similar to TypeScript owing to its lineage from Anders Hejlsberg. C# and .NET in its current form is a great language and platform to build on. Besides, if a team is already using VS Code, GitHub, and TypeScript, they're already in the Microsoft controlled ecosystem. [0] https://spectrum.ieee.org/the-top-programming-languages-2023 [1] https://github.com/CharlieDigital/playwright-scrape-api [2] https://github.com/CharlieDigital/js-ts-csharp [3] https://medium.com/servicetitan-engineering/go-vs-c-part-3-compiler-runtime-type-system-modules-and-everything-else-faa423dddb34 [4] https://www.techempower.com/benchmarks/#section=data-r21&test=composite&hw=cl [5] https://itnext.io/getting-functional-with-c-6c74bf279616 [6] https://arxiv.org/ftp/arxiv/papers/2110/2110.10246.pdf