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

261–270 of 287 posts

Re: .NET Orleans

#261

Post by vaindil »

Jaruzel wrote: post #206
pjmlp wrote: post #172

Earlier quoted context omitted.

Because .NET Core isn't fully compatible with .NET Framework, and there are lots of stuff which people are willing to spend money porting them. In the consulting business "I rewrote X in Y" blog posts only happen when someone takes the time to budget the project, because there is someone doing the math of developer time x cost per hour . Then .NET Framework has been Windows specific for 20 years, there are lots of .N…

> Because .NET Core isn't fully compatible with .NET Framework The roadmap is to collapse both into '.NET Standard' at some point. MS are committed to full cross-platform compatibility.

They're sort of dropping .NET Standard now in favor of .NET 5, which is the main path moving forward. https://devblogs.microsoft.com/dotnet/the-future-of-net-stan...

Re: .NET Orleans

#262

Post by nullsense »

manigandham wrote: post #236
nullsense wrote: post #193

Earlier quoted context omitted.

>.NET 5 is a merger of everything into a single framework again Is it a merger or a replacement? I won't be able to just take my huge legacy .NET 4.7.2 app and just change the runtime to .NET 5 and hit the go button right? Seems for the app I work on at least the upgrade path is a full rewrite :/

It's technically a merger. It's the next version of .NET Core after v3.0 but jumping ahead to v5.0 and dropping the "Core" designation, and then merging in parts of Mono, AOT toolchain, and even more of the (upgrade) bits of the classic framework. You might be able to get pretty far with just a framework switch. The RC is already out so try it. You'll probably have to update the csproj/sln files at a minimum and fix…

>but it's unlikely you need an entire rewrite.

My EF 5, EDMX, ancient dependencies and the like probably beg to differ.

Re: .NET Orleans

#263

Post by nullsense »

dragonwriter wrote: post #241
nullsense wrote: post #185

Earlier quoted context omitted.

>I want to love .net core - I really like F#. Any other rails dev out there make the transition to .net core? They're worlds apart. Rails is optimized for day 1, .net core is optimized for day 1000.

> Rails is optimized for day 1, .net core is optimized for day 1000. Sure, that’s a standard argument for statically-typed kitchen-sink enterprise-marketed languages and platforms like Java/JVM and C#/.NET. But having come in to maintain things on day 1000 (or, in some cases 5000) for projects in such languages and, also, languages that are far less strict and have less features designed to require/support tooling, i…

Sadly, that's been my experience too.

Re: .NET Orleans

#264

Post by smartbit »

FooBarWidget wrote: post #194

I'm involved in a project that uses Orleans. Conceptually and technically it's very interesting. Nodes automatically cluster together to form a big distributed system, and the concept of "virtual actors" make it possible to represent individual entities in the data model directly as actors, without worrying whether everything fits in memory at the same time. However, Orleans doesn't seem to play very well with Kubern…

Thanks for this insight. Skimming through the documentation [0], I find no ‘issues’ section that mentions this. IMHO Microsoft behaves untrustful by hiding an issue like this.

> Early in the start-up process and at runtime, the silo will probe Kubernetes to find which silos do not have corresponding pods and mark those silos as dead [1]

This is an experimental fix in a MR [1] that comes 6 years after Microsoft announced support for Kubernetes [2].

> Orleans was created at Microsoft Research and designed for use in the cloud. [0]

I read: MS research developed the concepts of .NET Orleans 10 years ago without having Orchestrators like Kubernetes in mind. Now as an afterthought they have to come up with some patches for it not to cripple on short-lived Kubernetes nodes.

A proper Operator & Helm chart was requested in nov 2017 [3] and the issue still is open. I get the impression that it is either not possible to write a proper Kubernetes Operator without a major rewrite of .NET Orleans or Microsoft has a commercial interest for .NET Orleans not being a first class citizen on Kubernetes.

Whichever it is, I’m not going near a Kubernetes cluster hosting .NET Orleans.

[0] http://dotnet.github.io/orleans/Documentation/index.html

[1] https://github.com/dotnet/orleans/pull/6707

[2] https://azure.microsoft.com/en-us/blog/azure-collaboration-w...

[3] https://github.com/dotnet/orleans/issues/3692

Re: .NET Orleans

#265

Post by reubenbond »

smartbit wrote: post #264
FooBarWidget wrote: post #194

I'm involved in a project that uses Orleans. Conceptually and technically it's very interesting. Nodes automatically cluster together to form a big distributed system, and the concept of "virtual actors" make it possible to represent individual entities in the data model directly as actors, without worrying whether everything fits in memory at the same time. However, Orleans doesn't seem to play very well with Kubern…

Thanks for this insight. Skimming through the documentation [0], I find no ‘issues’ section that mentions this. IMHO Microsoft behaves untrustful by hiding an issue like this. > Early in the start-up process and at runtime, the silo will probe Kubernetes to find which silos do not have corresponding pods and mark those silos as dead [1] This is an experimental fix in a MR [1] that comes 6 years after Microsoft announ…

Interesting take. We run Orleans on Kubernetes in production at Microsoft on multiple services. Other services run Orleans on Service Fabric in production - SF is similar to Kubernetes in terms of lifecycle. The project is open source, so things like Helm charts and k8s operators would be welcome contributions.

If you want to discuss, feel free to message me on Twitter (https://twitter.com/reubenbond) or Gitter (https://gitter.im/dotnet/orleans).

Re: .NET Orleans

#267

Post by manigandham »

FridgeSeal wrote: post #258
davidfowl wrote: post #220

Earlier quoted context omitted.

Just wait until .net 5 results show up ;)

Interesting, are there significant performance fixes in the mix? I always got the impression .net was never particularly performance focused: there were some bits you could use if you wanted to go a bit faster, but it doesn't seem designed from the ground up to be fast, and AoT compilation seems to be perpetually on the back-burner. Compared to other languages like C++ or Rust, which have been built for speed... Edit…

Saying "built for speed" doesn't really mean much. .NET created the async Task model that other languages adopted and has all kinds of performance related features from Span/Memory APIs to SIMD vector operations.

AOT doesn't have anything to do with performance but helps with startup time and packaging. The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.

C++ and Rust are faster because they don't have a managed runtime, and Rust's major innovation was moving as much of the memory management into a strong build-time analysis to ensure it's properly access. You can build low-allocation or more manual memory management with .NET and get very similar performance. RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/

Your comments are surprising since you seem to have experience F# and other languages and yet it sounds like you haven't used any modern .NET version.

Re: .NET Orleans

#268

Post by smartbit »

reubenbond wrote: post #265
smartbit wrote: post #264

Earlier quoted context omitted.

Thanks for this insight. Skimming through the documentation [0], I find no ‘issues’ section that mentions this. IMHO Microsoft behaves untrustful by hiding an issue like this. > Early in the start-up process and at runtime, the silo will probe Kubernetes to find which silos do not have corresponding pods and mark those silos as dead [1] This is an experimental fix in a MR [1] that comes 6 years after Microsoft announ…

Interesting take. We run Orleans on Kubernetes in production at Microsoft on multiple services. Other services run Orleans on Service Fabric in production - SF is similar to Kubernetes in terms of lifecycle. The project is open source, so things like Helm charts and k8s operators would be welcome contributions. If you want to discuss, feel free to message me on Twitter ( https://twitter.com/reubenbond ) or Gitter ( h…

Please feel free to explain here in HN

- why it took up to 6 years for MS to release an experimental fix [1] to run on Kubernetes?

- where I can find the outstanding issue in the release notes that [1] tries to fix?

- why Microsoft doesn't write and release an Operator & Helm chart, instead asking the community?

- if .NET Orleans runs fine on Kubernetes, why is there a need for an experimental fix?

Re: .NET Orleans

#269

Post by apta »

FridgeSeal wrote: post #186
manigandham wrote: post #142

Earlier quoted context omitted.

Lack of higher-level language features requiring code duplication/generation, a lean standard library usually necessitating 3rd-party packages, and an utterly terrible module system and fragile tooling setup. Go is still far better than JS, but both are behind in modules, packaging and overall structure as compared to .NET. gofmt is nice though, more languages should have that.

For all it's other woes, I've had like 80% fewer issues with Go's tooling than .Net's. - Getting packages installed: trivial - Getting clean builds: trivial - Build and run works near perfectly In comparison .net seems designed to be used _only_ via Visual Studio: - Why does it re-download the packages each time I ask it to build? - Why does VS freak out sometimes when there's a terminal window left over from a previ…

> - Why does it re-download the packages each time I ask it to build?

Are you using Nuget?

Re: .NET Orleans

#270

Post by fomine3 »

johnnycerberus wrote: post #227
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…

Why should a technology replace other technologies when it brings exactly the same things to the table that are possible with the technologies that it is meant to replace? Just because it gives you the feeling that you are under the dotNET umbrella? LINQ? Clojure and Scala can offer you much more than LINQ. Java is on par. dotNET Core libraries? I don't know, I have never heard people complaining much of the core lib…

I wish Java has LINQ. It has only non-friendly non-expandable LINQ-to-Object equivalent.

Example for bad parts: Handling checked exception in lambda, no extension method support, calling ".collect(Collectors.toList())" every time, no real closure support, complex lambda type due to primitive types.

I should mention async/await for C# feature compared to Java.

IMO Scala/Clojure is too much for me, C# is balanced option.

Post reply on HN