Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Orleans

dotnet.github.io

Post reply on HN
Print view View original

161–170 of 287 posts

Re: .NET Orleans

#161

Post by pjmlp »

Thaxll wrote: post #87
tmpz22 wrote: post #81

I spent some time learning dotnet core this year and with the slow-grind progress Microsoft has made it really does look like the technology stack might start to replace Java, Go, Rails, NodeJS, over the next decade. You can really feel Microsoft's experience in language development and enterprise software development coming together to provide better ecosystem ergonomics than other frameworks and toolchains. Specifi…

I'm pretty sure net core will remain for a long time in the enterprise world before making anything in the more open source / general public. It's 2020 I can't name a single server side known application built in net core.

Same here, our latest greenfield project was done in .NET Framework 4.7.2 and for the looks of it, the next one might be .NET Framework 4.8.

There are plenty of enterprise stuff like SharePoint, Sitecore, GUI components based on commercial partners like Telerik and Component One, among many others that are still on an transition to Core.

And for those that already moved there, their stability is still at v1.0 level, better leave the "fun" to others.

EDIT: typos and grammar.

Re: .NET Orleans

#162

Post by pjmlp »

manigandham wrote: post #146
Thaxll wrote: post #87

Earlier quoted context omitted.

I'm pretty sure net core will remain for a long time in the enterprise world before making anything in the more open source / general public. It's 2020 I can't name a single server side known application built in net core.

Sonarr/Radarr/Lidarr/Emby/Ombi/Jackett/Jellyfin are all very popular media servers and download managers built in .NET Bitwarden is a self-hosted lastpass/1password competitor in .NET You've probably used oauth somewhere powered by IdentityServer, played a game built in Unity, and used a mobile app built with Xamarin.

Unity uses a mix of .NET Framework, Mono and their own IL2CPP/Burst compiler stack.

In fact it remains to be announced what are their plans regarding .NET 5.

Re: .NET Orleans

#163

Post by SeriousM »

tmpz22 wrote: post #81

I spent some time learning dotnet core this year and with the slow-grind progress Microsoft has made it really does look like the technology stack might start to replace Java, Go, Rails, NodeJS, over the next decade. You can really feel Microsoft's experience in language development and enterprise software development coming together to provide better ecosystem ergonomics than other frameworks and toolchains. Specifi…

Programing languages are like patterns that may or may not fit in a developers head so they will not replace each other. I'm sure every developer can read all programing languages but it's about master the language and its eco system.

Re: .NET Orleans

#164

Post by atraac »

x0n wrote: post #106
celdon25 wrote: post #74

> Orleans builds on the developer productivity of .NET As someone who has developed with .NET (using VB, C#, F#) for almost 15 years, I am not sure if I would still advertise .NET as something focused on developer productivity, when in the context of introducing bleeding edge tech. It is a great framework, but I've found much more productivity with Elixir after just 1 year of using it. C# still suffers from statefuln…

I think maybe you stepped out of .net at the wrong time. Pattern matching, records, discriminated unions (c# 10) etc are here and on they way. Lots of functional features being integrated into C# with every update.

I'm using new c#/.net core professionally and I still think it's far less productive than elixir/phoenix in general. Also c#'s pattern matching is nothing when compared to elixir ones. They are very different languages though and that's fine, most people are familiar with OO, not with FP so for them, it might be more productive(at least in certain types of applications).

Re: .NET Orleans

#165

Post by cutler »

manigandham wrote: post #152
cutler wrote: post #137

Earlier quoted context omitted.

Blazor is currenlty hobbled by having to haul its runtime across the wire and is thus not in a position to compete with React or Vue.

The server-side model doesn't have this issue and the client-side WASM model is brand new with the first production release a month ago so it will get better soon. The browser runtime is trimmed down to the APIs actually used, has dynamic async loading now, and it's around the 1.5MB mark which is competitive with the big SPA payloads.

But those "big SPA payloads" contain the whole app. With Blazor you incur a 1.5Mb overhead before you've written any app code. That's simply unacceptable on many devices so Blazor's current implementation is only relevant for internal apps.

Re: .NET Orleans

#166

Post by pjmlp »

spaetzleesser wrote: post #130
atombender wrote: post #127

Earlier quoted context omitted.

Is there a document describing this plan? Will this replace .NET Core, CoreRT, etc.? As someone who isn't a .NET developer, the sheer proliferation of runtimes and platforms is super confusing, and I can never remember what's what between, .NET, .NET Native, .NET Framework, .NET Core, Mono, CoreRT, etc. If this is getting cleaned up, that's great news.

As far as .NET goes, MS has a long history of confusing messaging. As soon as something gets traction it either gets obsoleted or renamed. They would do themselves a big favor if they made it easier for people to understand the different versions.

Not only .NET, I am really pissed how C++/CX got replaced with C++/WinRT, without any effort to provide tooling with similar capabilities.

So instead of a C++ with C# like tooling for doing UWP stuff, now one gets to edit IDL files without any kind of support (you could be using Notepad for what they care), and then you have to manually copy/merge C++ files after being generated.

And on the .NET side .NET Native was looking to be how version 1.0 should have been all along, and now has an uncertain future.

Finally with Reunion, when going regularly on their issues, it seems to be turning into a major reboot, porting what they can into Windows 7 like stack, leave UWP as an improved COM runtime, and pretend that everything else post Windows 8 outside Win32 never happened.

Re: .NET Orleans

#167

Post by manigandham »

tempfs wrote: post #155
manigandham wrote: post #90

Earlier quoted context omitted.

It already has replaced those (or prevented them from ever catching on) in thousands of companies. .NET was always fast and highly productive, and the last 5 years of .NET Core have taken it to the next level. The language stack is unmatched in terms of how quickly you can make a high-quality product across many different platforms.

Fast? #lolno

Do you have some evidence or more substantive feedback? Because I can show you the techempower benchmarks which have it in 1st and 3rd place at over 7 million rps: https://www.techempower.com/benchmarks/#section=data-r19&hw=...

I built an adtech platform doing millions of requests in 2010 in dotnet. Then I did it again doing billions of requests in 2012. Nothing else at the time other than java could come close with the same amount of effort.

Re: .NET Orleans

#168

Post by manigandham »

cutler wrote: post #165
manigandham wrote: post #152

Earlier quoted context omitted.

The server-side model doesn't have this issue and the client-side WASM model is brand new with the first production release a month ago so it will get better soon. The browser runtime is trimmed down to the APIs actually used, has dynamic async loading now, and it's around the 1.5MB mark which is competitive with the big SPA payloads.

But those "big SPA payloads" contain the whole app. With Blazor you incur a 1.5Mb overhead before you've written any app code. That's simply unacceptable on many devices so Blazor's current implementation is only relevant for internal apps.

Same with Blazor. The mon.wasm runtime is around 400kb compressed and the biggest DLL is mscorlib at 600kb. The actual DLLs for the app are just a few kb.

Here's a very old build: https://blazor-demo.github.io/

And a recent build: https://stevesandersonms.github.io/BlazorOnGitHubPages/

Yes you can be smaller with JS but not by much these days, and given the amount of functionality you get with Blazor it's hard to compare on file size alone. Also if you're just making internal apps with controlled usage then server-side is better anyway.

Re: .NET Orleans

#169

Post by thdrdt »

manigandham wrote: post #115
dmitryminkovsky wrote: post #98

Earlier quoted context omitted.

Very cool, thank you for sharing. > It's much more advanced and functional than React already. I’m sure this is true, but I can’t imagine there’s much of a community around it? The thing is with React you have a huuuuuuge community and ecosystem. You can share code with React Native. It’s so deep...

Well Blazor is new so React will have a bigger community, however there are millions of C# devs around the world and they can be instantly productive with Blazor so it shouldn't be that far behind, if at all. While React's ecosystem might be huge, the quality trails off quickly and it's pretty messy even with the popular stuff, much of which is to add functionality that every app needs but isn't included in React its…

I like Blazor, but to be fair, coming from VueJs, it feels not finished. Some things are just more complicated that they should be. But things are changing, so we will see what happens in the next releases.

Re: .NET Orleans

#170

Post by tasogare »

celdon25 wrote: post #74

> Orleans builds on the developer productivity of .NET As someone who has developed with .NET (using VB, C#, F#) for almost 15 years, I am not sure if I would still advertise .NET as something focused on developer productivity, when in the context of introducing bleeding edge tech. It is a great framework, but I've found much more productivity with Elixir after just 1 year of using it. C# still suffers from statefuln…

> null references

This is addressed since C# 8.

Post reply on HN