Offtopic but I really really like C#. Such a great and easy language to work with! It's a shame that people do not choose it over Java because of M$-bad rhetoric :(
It took several versions of the language to have readonly and records. Non-null references are just a bunch of compiler warnings rather than a first-class type.
Generics work, but type constraints are a joke. In particular, the ~new()~ constraint shows the disregard MS has always had for object-oriented programming: objects are supposed to be fully constructed; parameterless constructors are to be the exception, not the rule. On a similar note, record struct insist on having a parameterless constructor that cannot be disabled.
Furthermore, the language is mildly-typed (I'd say strongly if it wasn't for non-null references), but the framework is not typed at all! How people could write "public virtual bool Equals(object other)" with a straight face is beyond me!
Well it was created before generics in .NET one and can't be removed, that's the simple answer. But yeah, making object equality customizable virtually was probably the worst design mistake in C# and .NET. Having to specify the comparer explicitly when creating e.g. a Set collection would have been so much better for quality.
The second worst mistake was defaulting CultureInfo to the system culture (i.e. making methods like float.Parse()/ToString() take the system culture into consideration instead of requiring everyone to pass in the required behavior)
Then I found out about the ability to introspect and modify lambda expressions and generate code at startup time, which obviated the need for a template with constrained new, and I was blown away by that power.
I was also very pleasantly surprised that C# had very easy to use multiple dispatch.
So, C# is an extremely powerful, but you can't always port C++ idioms 1:1.
edit: and before you ask, yes, I'm a recovering complexity addict.
.NET 1.0 was a direct copy of Java, so these Object methods are inherited from there.
It's compatible enough that it's possible to transpile Java Bytecode to run on the .NET runtime and vice-versa.
This depends a lot on what you want to do in your program. Of course, for example, for interacting with other Microsoft technologies, .net has a better ecosystem.
About as easy as Python, at least.
Which, for MS, made a lot of sense, they wanted to hook win32 apis. Java doesnt care, as much...
unsafe
{
[DllImport("libc", EntryPoint = "write")]
static extern nint Write(nint fd, byte* buf, nint length);
var text = "Hello, World!"u8;
fixed (byte* ptr = text)
{
Write(1, ptr, text.Length);
}
}But, I'm still not entirely convinced Microsoft has changed their ways (not that Oracle is any better...), particularly because of the things mentioned here: https://isdotnetopen.com/
Last time I checked, they reversed their decision regarding the proprietary vscode extension, which is great, but the debugger situation hasn't changed & that makes me question whether it's worth switching.
It's a very pleasant language to work in, especially compared to Java, but there are so many other really nice C adjacent languages in the field that it's hard to argue for if you're not in that ecosystem.
It appears to have been the case since .net 5 (2020) (I've also stopped paying attention to MS a bit before then).
"Yes, .NET 5 is cross-platform and can be installed on Linux, Mac, and Windows. It aims to provide a consistent development experience across platforms by unifying different .NET flavors, including .NET Core, .NET Framework, .NET Standard, and Mono. .NET 5 also aligns all frameworks to support a common set of APIs, making it easier to build cross-platform libraries."
So in theory it's all independent but in practice the best bits are still on Windows.
There are decent third party open-source libaries like SixLabors/ImageSharp that have stared to fill the gap.
Missing a Graphics Library in .NET (5-8) is just half the story. It's of course missing an entire UI library too. But Microsoft, perhaps wisely, chose not to also implement a whole xplat UI library. Avalonia/Uno/etc are already there.
The other one is that it is not always clear the context on which you can use certain APIs.
The language is truly lovely to work in, moreso than I think it gets credit for unless you've a lot of experience with it. It's just very thoughtfully designed, and MS support their own components really well and for a very long time.
The problem is that NuGet never became npm, gem or pip. The open-source community never really embraced C# (for understandable reasons) and it meant that the void there was filled largely by projects that couldn't get much traction and enterprise component vendors like Telerik.
I'm not in any way knocking companies that make their money selling these components by the way, I just think the message that people looking from the outside are seeing (rightly or wrongly) is that there's a tax payable to third parties on absolutely every level of this stack so why build with it? What's my incentive to start learning it when I can pick up node / React / Next / Python / etc. for free and start working right away with free tools? And that all shows in the ecosystem.
OSS adoption is an ongoing process, that doesn't happen overnight. The attitude in this and adjacent comments is a good showcase that even after 8 years, once your average developer has settled in a particular mindset, it becomes a matter of enforcing tribal consensus even when the facts change.
If you also ever actually used .NET and nuget packages (in a post-netframework period), it would be apparent that the statement is simply not true.
If I need a package to perform a task that I think other people surely must have brushed up against in the past then I know it almost certainly exists in npm. That’s just not true for NuGet, as much as it would be better for the ecosystem if it was. This shows in the contributions to each, and the contributions (in terms of volume) are much higher for npm.
I specifically noted the post-.NET Framework experience. It is a continuous problem that community demands from the standard library and/or sdk to ship something it has no business shipping (like the sibling comment complaining about System.Drawing, it is truly an 8th OSI layer issue). And when there's an OSS solution, there is a stark difference in comments between developers who understand that OSS projects are projects of collaborative development (meaning that submitting and issue you care about may involve a degree of contribution) and the ones which demand paid level of support for free.
JavaScript is also just generally massive. Surely you're not going to hold it against Rust that Rust projects are less frequently contributed to? C# and .NET are unique language and platform which do overlap with Java and JVM, and other similar class of tools but do solve problems the latter cannot, or solve the ones that they can but in a frequently better way (for example: trying to reach performance ceiling in Java requires way uglier tricks with worse results rather than writing clean byref/pointer based C# code with structs and struct generics).
Here’s 8 third-party libraries I have published on nuget in the last ~7 years: https://www.nuget.org/profiles/ConstMe
Only one of them is an SDK for a cloud service, but it’s unofficial SDK. I have no affiliation to pcloud, I only use the free version, I just carefully implemented the documented TLS/TCP binary protocol to access their cloud.
None taken.
> computervison project in c#
Yeah, for CV applications nuget.org is indeed not particularly great. Very few people are using C# for these things, people typically choose something else like Python and OpenCV.
BTW, same applies to ML libraries, most folks are using Python/Torch/CUDA stack. For that hobby project https://github.com/Const-me/Cgml/ I had to re-implement the entire tech stack in C#/C++/HLSL.
The biggest example are PDF producing/converting libraries, which I have no doubt make millions in licensing.
For example, even probably their best product VS Code only got reasonable multiple screens support last year: https://github.com/microsoft/vscode/issues/10121#issuecommen...
And then, on the other end of the spectrum, you have Teams and ecosystem surrounding it. The "fun" of Teams bot integrations and the mess with SDKs and SDK documentation for it — never again.
If M$ is bad, Oracle is Beelzebub.