.Net is part of the FOSS ecosystem.

In the same sense Chromium and Android isn't controlled by google yes.

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

It's pretty obviously a failed experiment. Why keep repeating it? Try again in another 3 months.

The answer is probably that the Copilot team is using the rest of the engineering organization as testers. Great for the Copilot team, frustrating for everyone else.

> It's pretty obviously a failed experiment

For it to be "failed" it would have to also be finished/completed. They are likely continuously making tweaks, this thing was just released.

"This thing has just released"

"It would have to be finished/completed"

Do you honestly not see a problem with those two statements in such close proximity? Is it finished or is it released? The former is supposed to be a prerequisite for the latter.

It's unfinished and it's in the public's hands. I don't see these as opposing ideas.

We can debate whether they should have called this an experiment or an alpha or beta or whatever, but that's a different discussion.

The fact that people are using it currently does not make it a failure. When MS shuts it down, or Copilot is wildly unprofitable for multiple quarters, team behind it quits, etc, etc, then we can determine whether it has failed or not.

But if they continue to have paying customers and users are finding some benefits over not having Copilot, and MS continues to improve it (doesn't let it rot), then you'd have to provide some evidence of its failure that isn't "look at Copilot being stupid sometimes". Especially when stupidity is expected of it.

What bliss it must be, to never have encountered Microsoft software before.

oh, how I wish you were right... I had to look deep inside some microsoft software, and I think it actually shortened my lifespan

I wouldn't necessarily call that just an experiment if the same requests aren't being fixed without copilot and the ai changes could get merged.

I would say the copilot system isn't really there yet for these kinds of changes, you don't have to run experiments on a language framework to figure that out.

By all means. Just not on one of the most popular software development frameworks in the world. Maybe that can wait until after the concept is proven.

Yeah, seems to me that breaking .NET with this garbage will be, uh, extremely bad

Nah I'd prefer they focus on writing code themselves to improve .NET not babysitting a spam-machine

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

(Corrective upvote from me. Pretty much any use of reflection dooms you, and reflection is very common.)

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.

NPE itself isn’t likely to be exploitable, no, but what I had in mind was more along the lines of code with logic errors handling rare cases where something is null. There’s a lot of tooling designed to catch things like that but the worst code bases tend not to use them because they’d need a lot of cleanup.

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

Looks like the author is explicitly excluding "Error", "StdDev", "Median", "RatioSD" from the ouput. It's in the setup[0]. I'm guessing the author omitted them for brevity.

[0] https://devblogs.microsoft.com/dotnet/performance_improvemen...

edit: meant "excluding", not "including"

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

Are you suggesting a Result type and Exceptions are mutually exclusive? Scala bolted `Either` (a Result type) on top of Java, and it worked exceptionally well in my experience.