svick

.Net is part of the FOSS ecosystem.

You don't want them to experiment with new tools? The main difference now is that the experiment is public.

Half of the .Net ecosystem doesn't work with AOT either.

A NullPointerException is not a security vulnerability.

A race condition might, but even then, I'm not sure how likely that is to result in a vulnerability in a garbage collected language.

UTF-8 string literals will be part of C# 11/.Net 7, which could help. But they're still more awkward to use than the UTF-16 string.

Many of the benchmarks are using BenchmarkDotNet, so consider reporting this to them: https://github.com/dotnet/BenchmarkDotNet/.

Many developers distrust closed source developer tools, whether they are free or not.

There is VS Code, which is not a version of VS, is free, and has this debugger.

There is also VS Community, which is a free version of VS, has this debugger, but has fairly strict licensing limitations (e.g. it can't be used in corporations).

Note that Mono, the framework, is indeed dying. But Mono, the runtime, is now part of .Net and it's an alternative to CoreCLR, used for things like Xamarin/MAUI and Blazor.

Though most of the time, you don't need to know any of this, you just use .Net and it works on Windows, Linux, Android, Apple and in the browser.

For null, there are nullable reference types now.

Exceptions are here to stay though. I don't see how you could retrofit something like Rust's Result on top of .Net. (Also, .Net has a pattern that's an alternative to exceptions: `bool TrySomething(out T result)`. But it's quite limited, in several ways.)

Yes, you can debug .Net using LLDB if you use the open-source SOS extension: https://docs.microsoft.com/en-us/dotnet/core/diagnostics/sos....

Nobody does anymore, so I don't see how that counts as a valid criticism of current .Net.

How do you differentiate between "actually abandoned and probably dangerous" and "actively maintained, but updated only very rarely, because there's nothing left to do"?

> While writing it I needed something that would be 'just data' without any additional 'functionality' attached to it, so I naturally reached for `struct`, given that it exists in the language. The .NET guys asked why it was not a `class` instead. See, somewhere deep inside they felt that not wrapping everything in a `class` is wrong on some fundamental level.

The difference between a class and a struct in C# is not the same as between a class and a struct in C++. In C#, structs can definitely be useful, but also have some gotchas, so they're mostly used only in performance-critical parts of the code.

If you visit a foreign tribe, I think you should listen to the locals, unless you are really certain your way of doing things is better in the local context.

I think there's at least one way in which F# is a second-class citizen: documentation. The documentation for anything in .Net will contain code in C#, but code in F# is quite rare.

So if you want to use F#, I think you still need to be able to read C# code.

I think there is zero chance of that happening.

MS recently made one tiny decision that was unfriendly to open source, it caused a huge outcry and a reversal within 48 hours on a weekend. I can't even imagine what the reaction would be in your scenario.

Besides, basically everything is open source now and you can't put that genie back into the bottle.

I guess they could do that, but what makes you think they actually will?

> ASP.NET Is the web framework that comes with .NET

Not quite. ASP.NET is the web framework that comes with .NET Framework. ASP.NET Core is the web framework that comes with .NET Core and .NET.

> .NET Framework refers to every version of .NET 4.8 and before.

It was fine to call .NET Framework 4.8 just ".NET 4.8" in the past, but I would avoid it now, to clearly separate .NET Framework 4.8 from .NET 5.0.

Keep in mind that it's just one option. If you want, you can still deploy your app separately from the .Net runtime.

Also, to keep the size at least somewhat in check, unused parts of the base library are not included in the single-file mode.

I believe it's at least partially true, because new cars are designed to be damaged in crashes, to better protect the people inside them.

> But you can't put two different kinds of things on the same belt lane without creating some serious trouble.

Sure you can, it's called a "sushi belt" and with some simple combinators, it can work reasonably well.

> So one of the prime dreams of having .net AOT of having an easy way to create a COMPACT self contained native exectuable dies when it hits real code.

They are working on improving that: https://github.com/dotnet/designs/blob/master/accepted/2020/...

Or maybe there isn't a single "the whole point" and it can be useful for different reasons to different people?

Starting with .Net 5, there will be one major release exactly once a year, and one LTS release exactly once every two years.

(see https://devblogs.microsoft.com/dotnet/introducing-net-5/)

The article says there was an issue with reimbursement. It doesn't say that the issue wasn't resolved or that it was MS's fault, both are just your conjecture.

> You use it.

They didn't use any of AppGet's code.

Though nobody is questioning whether what MS did was legal. The issue is whether it was moral.

> Interesting question would be whether WinGet is a "derivative work" of AppGet.

They don't share any code. As far as copyright law is concerned, it is not a derivative work.

I believe they didn't actually fork his code, what they did is build a brand new project that is heavily inspired by AppGet.

Also, they have now corrected the credit: https://devblogs.microsoft.com/commandline/winget-install-le...

> C# is as verbose as it was years ago.

It isn't. Pretty much every release (including C# 9.0) adds some features that make your code more concise.

I like the direction .Net is attempting to go here: there is a foundation and if you want your project to be taken seriously, you should join it. You still get to maintain your project (mostly) the way you want to, but if you stop maintaining the project, the foundation will take over.

(.Net is probably not unique in this regard, but it's what I'm familiar with.)