Live data from Hacker News

.NET 8

devblogs.microsoft.com

251–260 of 374 posts

Re: .NET 8

#251

Earlier quoted context omitted.

.NET/C# + Visual Studio [Code] + Azure DevOps + Azure Cloud = Everything is guaranteed to work for what a software company needs, with full documentation, examples, and a history of variants to explore. You simply don't have to spend too much time researching what to do, just follow the docs and get started writing code and delivering features. If you stray from the full integration of MS products, you start to lose…

No love for AWS huh? I've been impressed by how well their Lambdas work with NativeAOT (they make first-party effort to support it) for low cold-start latency. They have even sponsored further development of Dapper AOT recently. It's crucial for other major players on the market to participate in .NET if we want to ensure its longevity.

Azure offers a lot of instrumentation/telemetry out of the box compared to AWS.

The more time I spend with AWS the less I like it. Simple issues are left unfixed, implementations are half baked, tooling incomplete.

e.g:

Their configuration extensions package still doesn't support loading a single SSM parameter, despite someone going to the effort of submitting a PR nearly a year ago.

There's zero support for YAML cloudformation templates in their VS extension.

There's no package that allows you to send OpenTelemetry data directly to XRay, they expect you to run an entirely separate container.

The whole platform feels like a jumble of half baked, and poorly exposed services that end up being outright painful to work with.

Re: .NET 8

#252
post #204
post #89

Earlier quoted context omitted.

Oh, I see. I was hoping for something new. I keep on hoping some sort of BEAM-like (from Erlang) process gets added to .NET.

You might be interested in Orleans: https://learn.microsoft.com/en-us/dotnet/orleans/overview

Orleans is definitely interesting, but I have never looked into it much because it's my understanding that it is a cloud-only solution, in that it requires some Orleans or Azure service. Is that correct?

Re: .NET 8

#253
post #182

Blazor actually looks compelling now that it has server side streaming and rendering, as well as component level interactivity. Once .NET is integrated with the new WasmGC features, it will get even better! (I don't think they mentioned WasmGC on the roadmap but I can bet anything they're going to do it).

I am slightly surprised they still did not replace it with some 80% similar "WasmUI". Which XAML framework are we on now by number?

You could run Maui with canvas rendered controls. Just some coding work away.

But honestly, .NET is a enterprise thingy. Normal for them is that they coexist with angular, react, and many other UI toolkits. Reuse of css and web components is the customer need, not a Silverlight.

Re: .NET 8

#254

Earlier quoted context omitted.

.NET is stable, they very rarely remove things. Code written for .NET Framework 2.x will probably work fine on .NET 8 (unless it uses the things that didn't make the jump, like WCF, but there are libraries that provide SOAP support.) Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs. And the t…

> Code written for .NET Framework 2.x will probably work fine on .NET 8 WebForms would like a word.

Hence “probably”. WebForms should die in a dumpster fire.

Re: .NET 8

#255
post #158

Earlier quoted context omitted.

I think an issue here is that .NET was closed source for most of its existence. It was only 2019 when Microsoft announced that the open-source .NET would be the future of .NET. That will mean that a lot of startups wouldn't have chosen it. Even now, it means that a lot of the "trendier" devs will have learned other ecosystems that have been open source for longer. It takes time to shift developers.

Microsoft started open sourcing .net framework on 2007 with 3.5 version. The roslyn compiler is open source since 2014. I guess it's fine if people don't like .net but I think the open source part is not that relevant.

I think it depends on who you are. In 2007, a lot of people distrusted Microsoft and with good reason. They'd spent a lot of time extinguishing competitors. .NET Core was initially released in 2016, but Microsoft wasn't saying that .NET Core was their plan for the future. It seemed like an experiment they'd likely kill off or that it might just be a small subset of .NET.

I think saying that Microsoft started open sourcing .NET in 2007 feels a bit disingenuous. Plus, wasn't it source-available under the Microsoft Reference License? Regardless, .NET was still tied to Windows unless you wanted to use Mono (which was slow and had an uncertain future).

If you were someone who developed on Mac or Linux and deployed to Linux, you couldn't choose .NET in 2007 or 2014. Even in 2016, are you going to choose a brand-new ASP.NET Core? Microsoft announced .NET Core 1.0 at the Red Hat Summit in 2016 which isn't exactly an endorsement that the company thought it was the future of .NET. It seemed like Microsoft was trying to open up just enough to hook a company on .NET Core and then tell them "well actually, you should really upgrade to the real .NET Framework on Windows" when they ran into problems. That's not what happened, but Microsoft certainly hadn't committed to .NET Core in 2016. Their messaging was "well, Red Hat will offer support for this thing we made."

If I didn't have a Windows PC in 2015, I couldn't do .NET development (Mono aside). If I wanted to deploy to Linux in 2015, I couldn't do .NET development (Mono aside). The open source part matters to lots of people because .NET simply wasn't a choice for those who didn't want to be beholden to Windows and licensing until recently. People definitely ignored .NET because it simply wasn't an option for them.

Re: .NET 8

#256
post #158

As full stack .net dev, I am so disappointed every “who is hiring” thread. I would be game to join a trendier group of like minded devs but if you get one .net posting you are lucky, and it’s most likely rockstar. :(

I think an issue here is that .NET was closed source for most of its existence. It was only 2019 when Microsoft announced that the open-source .NET would be the future of .NET. That will mean that a lot of startups wouldn't have chosen it. Even now, it means that a lot of the "trendier" devs will have learned other ecosystems that have been open source for longer. It takes time to shift developers.

It was 2016 when you count official releases, open sourcing .NET to MIT started in 2014 including huge parts of the .NET Framework.

It is soon 10 years. With 14 years of closed source before. But honestly, it is not .NET which is the problem maker, it is Visual Studio on Windows. Because that is the thing which cost and the thing which only runs on Windows. I hope they fix it in favor of VS Code (which looks good right now).

But I agree. It takes time.

Re: .NET 8

#257
post #158

Earlier quoted context omitted.

I think an issue here is that .NET was closed source for most of its existence. It was only 2019 when Microsoft announced that the open-source .NET would be the future of .NET. That will mean that a lot of startups wouldn't have chosen it. Even now, it means that a lot of the "trendier" devs will have learned other ecosystems that have been open source for longer. It takes time to shift developers.

Microsoft started open sourcing .net framework on 2007 with 3.5 version. The roslyn compiler is open source since 2014. I guess it's fine if people don't like .net but I think the open source part is not that relevant.

More important than being open source was the fact that it was Windows only for the first 15-ish years of its existence.

Mono never got traction within the startup culture. In part, because it operated in a legal grey area for many years regarding MS patents for web (or web adjacent) technologies like ASP.NET and ADO.NET.

Re: .NET 8

#258
post #234

Earlier quoted context omitted.

I don't know Go that much, but the part about .Net is so untrue. First, C# was published in 2001, while Go was released in 2009. So there's 8 years of "more stuff". Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking. .Net 7 and 8 did also (IMHO)…

Do you want to compare the number of features added between go and c# in the last 15 years? Just a single major release of C# added more stuff than probably the last 15 years of Go. I'm not saying Go is 100% right in that, but it's much more conservative about stuff added into the language.

Of course, they conservatively added the most idiotic way of formatting dates as strings (while knowing other methods exist). And, while the whole bunch of other languages would call a method string.startsWith("a"), they use hasPrefix. This language is a mix of half-baked concepts and utter trolling. If I have to learn a lang with an awkward syntax, I'd prefer Rust, Julia, Erlang, Elixir or Haskell. Go is no-go. It's not even widely used at Google, its creator. So no, thanks.

Re: .NET 8

#259

I'd love to hear from some .NET fanatics, how would you convince someone to use that ecosystem over another?

C# design team is ~5 talented well paid engineers who think how to improve language for past 20 years, every week and don’t let flawed features in and can spend years on how to add async/await, nullables, SpanT and many other features so whole language makes sense and is joy to use. And they have another ~20 engineers implementing features in Roslyn making sure performance of IDE and compiler is acceptable and bug ~f…

This is to the point! That is why C# evolved so quickly and does not spiritually or factually broken.

Re: .NET 8

#260
post #50

Earlier quoted context omitted.

Are those new? What are they by name?

.NET has had first-class parallelism and async/await since around .NET Framework 4.0 release which was...13 years ago huh. There have been many improvements in the underlying runtime since then though. A garden variety of keywords is async/await, TPL (tasks/futures and structured concurrency) and PLINQ (Rust's Rayon).

You're right the basic support's been around a long time. However, originally you always had to use Task methods. The pleasant async/await keywords didn't arrive until C# 5.0, in 2012.

Admittedly that's also a long time ago.

Post reply on HN