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

91–100 of 287 posts

Re: .NET Orleans

#91

Post by dmitryminkovsky »

tmpz22 wrote: post #86
dmitryminkovsky wrote: post #85

Earlier quoted context omitted.

Not sure this will happen given Node/Typescript/VSCode (also Microsoft, fun how they’ve taken over Node right?) but the dotnet platform sure is rich. I had the opportunity to work with it this year and I found it to be very nice! Not surprised to see it gaining more and more momentum with libraries like this.

The coup de grace is functioning and sane server side rendering of ReactJS apps by c# applications. If Microsoft can make that easy and simple it will lead to a huge churn as many software companies replace less efficient nodeJS applications for that use case. Typescript will always have its placed client-side but there will be huge user benefits if we can have more and better server side rendering.

I really enjoy how TS is the same on server and client. The C# runtime is way richer, but I like the TS type system more. Not sure I’d want to use different platforms on backend/front end even if C# did server rendering like React.

Re: .NET Orleans

#92

Post by popinman322 »

reubenbond wrote: post #23

I'm a core developer on Orleans. Feel free to ask any questions here, or on gitter: https://gitter.im/dotnet/orleans I gave a talk recently on how we use it at Microsoft: https://www.youtube.com/watch?v=KhgYlvGLv9c - the talk is very short and so it does not go into many details, but it gives an overview of some internal use cases.

Are there any good resources on combining projects Orleans and Coyote?

https://microsoft.github.io/coyote/

Re: .NET Orleans

#93

Post by FridgeSeal »

qz2 wrote: post #67

I’ll give it three hours before the emperor is found naked, like COM, DCOM, DNA, windows.net, Patterns and Practices, Enterprise Library, Remoting, AppFabric, WCF.

It's a "Microsoft Framework", it's going to be enterprise-y Design-Patterns, convoluted abstractions, Dependency-Injection-on-Dependency-Injection and MS specific code/libs all the way down.

Re: .NET Orleans

#94

Post by manigandham »

tmpz22 wrote: post #86
dmitryminkovsky wrote: post #85

Earlier quoted context omitted.

Not sure this will happen given Node/Typescript/VSCode (also Microsoft, fun how they’ve taken over Node right?) but the dotnet platform sure is rich. I had the opportunity to work with it this year and I found it to be very nice! Not surprised to see it gaining more and more momentum with libraries like this.

The coup de grace is functioning and sane server side rendering of ReactJS apps by c# applications. If Microsoft can make that easy and simple it will lead to a huge churn as many software companies replace less efficient nodeJS applications for that use case. Typescript will always have its placed client-side but there will be huge user benefits if we can have more and better server side rendering.

You can already do that by running Node with SSR (or any npm/js code) in .NET using Node Services [1] or use ReactJS.NET that packages everything for you [2].

But Microsoft won't officially do any more since they have Blazor which lets you run C#/.NET in the browser with both client-side WASM and server-side SignalR/websocket running modes. It's much more advanced and functional than React already. [3]

1. https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-S... 2. https://reactjs.net/ 3. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Re: .NET Orleans

#95

Post by manigandham »

dmitryminkovsky wrote: post #91
tmpz22 wrote: post #86

Earlier quoted context omitted.

The coup de grace is functioning and sane server side rendering of ReactJS apps by c# applications. If Microsoft can make that easy and simple it will lead to a huge churn as many software companies replace less efficient nodeJS applications for that use case. Typescript will always have its placed client-side but there will be huge user benefits if we can have more and better server side rendering.

I really enjoy how TS is the same on server and client. The C# runtime is way richer, but I like the TS type system more. Not sure I’d want to use different platforms on backend/front end even if C# did server rendering like React.

You should try Blazor first: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Re: .NET Orleans

#96

Post by keithnz »

chrisseaton wrote: post #33
jolux wrote: post #31

Earlier quoted context omitted.

"in anger" typically means for a real-world, serious project.

Is this a Britishism? I find Americans often are confused by it when I use it.

I'm from New Zealand, so maybe! never knew it was not a thing in America.

Re: .NET Orleans

#97

Post by bovermyer »

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…

Disregarding popularity, why should I switch to C#/dotnet from PHP/Go/Ruby?

Re: .NET Orleans

#98

Post by dmitryminkovsky »

manigandham wrote: post #94
tmpz22 wrote: post #86

Earlier quoted context omitted.

The coup de grace is functioning and sane server side rendering of ReactJS apps by c# applications. If Microsoft can make that easy and simple it will lead to a huge churn as many software companies replace less efficient nodeJS applications for that use case. Typescript will always have its placed client-side but there will be huge user benefits if we can have more and better server side rendering.

You can already do that by running Node with SSR (or any npm/js code) in .NET using Node Services [1] or use ReactJS.NET that packages everything for you [2]. But Microsoft won't officially do any more since they have Blazor which lets you run C#/.NET in the browser with both client-side WASM and server-side SignalR/websocket running modes. It's much more advanced and functional than React already. [3] 1. https://cha…

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

Re: .NET Orleans

#99

Post by popinman322 »

withinboredom wrote: post #80
Izikiel43 wrote: post #24

Earlier quoted context omitted.

> Just don't make any bugs in your code or you're in for a headache. Have you taken a look at this? https://microsoft.github.io/coyote/ https://microsoft.github.io/coyote/learn/overview/what-is-co... It's a tool by Microsoft Research to detect concurrency bugs in code.

I feel like the documentation (or something) could be improved there. I've never been able to get it to find a bug. That said, there's also https://github.com/Azure/azure-functions-durable-extension which seems closely related to Orleans, but for serverless.

Durable Functions are not in the same category as actors. Each durable function exists to serve a single request; the model is request partitioned instead of data partitioned.

Durable Functions are great for deterministic synchronization across calls to other Azure Functions. Fan-out, fan-in, function chaining, and similar tasks are best done using Durable Functions[0].

Could you build an actor model on top of Durable Functions? Possibly. I'm not sure why you would do that, though. Azure Functions are already pretty expensive.

[0]: https://docs.microsoft.com/en-us/azure/azure-functions/durab...

Post reply on HN