281–287 of 287 posts
Earlier quoted context omitted.
> - Why does it re-download the packages each time I ask it to build? Are you using Nuget?
Yeah, normal Visual Studio setup, nothing particularly out of the ordinary as far as I know. Does it not do that for you?
Earlier quoted context omitted.
Which libraries? Could you give some examples?
Just off the top of my head, there are .NET copies of: - Akka https://github.com/akka/akka - Lucene https://github.com/apache/lucene-solr - Aeron https://github.com/real-logic/aeron - Retrofit https://github.com/square/retrofit Not to mention projects like Apache Spark, Cassandra, Elasticsearch, Druid - Java projects. Many projects (Foundation DB, Scylla DB, I could find more) will have in-house support for Java and…
TensorFlow can run on any JVM for building, training and running machine learning models. They have created recently https://github.com/tensorflow/java
PyTorch also supports inference on the JVM but you still need to train with Python. https://www.infoq.com/news/2020/02/pytorch-releases-java-bin...
I think something like Scala will be used in the future instead of Python even for prototyping.
Streaming is also big business on the JVM: Apache Kafka https://kafka.apache.org/ (80% of Fortune 100 companies use it) Apache Flink https://flink.apache.org/ Apache Storm https://storm.apache.org/
Hard to think that .NET ecosystem will ever reach the ecosystem of Java when it comes to open-source.
Earlier quoted context omitted.
To be fair: .NET (Framework) was not fast in the past. It was not. It was really slow. It was exclusively on Windows, IIS, some worker module, piped through a Webforms optimized System.Web dll and most of that code not optimized for memory usage etc. But that is over with modern .NET Core. Nothing of above is valid anymore and the result is wicked fast as your link shows as evidence.
Oaiey, .NET is not synonymous with WebForms.
I would recommend some early talks from Damian Edwards or David Fowler about ASP.NET Core. They are very explicit about that (in the end they build Katana replacing System.Web on .NET Framework to allow a better ASP.NET MVC performance, which lead to Project "K", which lead to (ASP).NET Core).
Speaking as one fanboy to another ;)
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.
Earlier quoted context omitted.
> - Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order) I thought Erlang only guaranteed that if the processes are on the same node. Is that not correct?
It’s true even with distribution, see e.g.: http://erlang.org/faq/academic.html#idp33052176 http://erlang.org/pipermail/erlang-questions/2017-September/...
For a long time I was curious how Akka Artery preserved message ordering for it's 'dedicated large message' lane. in short it really just means you are dedicating a specific TCP or Aeron connection dedicated to those actors, there's no magic ordering sauce underneath. (just a little disappointed to find that out, but appreciate the simplicity upon consideration.)
Earlier quoted context omitted.
Academically (And, to some extent, practically speaking) Orleans Virtual actors aren't the same as Erlang (or Akka) actors. Major differences: - Normal actors are pretty flexible, can work in local or remote contexts. Orleans is probably best described as Sharded Actors, It's a 'guided' implementation of Actors compared to Erlang or Akka where you are given a toolkit and have to build out what you intend to do. - Orl…
> Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order) Ordering has a performance cost. It needs to either be maintained at all levels, or reconstructed from unordered messages at a later point. Even something simple like an m:n th…
Yep, although it's not typically as bad as it sounds even in Akka/Erlang; TCP gets you most of the way there. It does however become a problem when want to try to scale 'out' (i.e. use multiple links for message prioritization, etc.)
> Likewise for Orleans, but the caveat of a "stable cluster" doesn't do much for users. "Stable cluster" falls apart frequently in real scenarios, which can be as simple as a single machine being abruptly restarted. Developers must account for the error scenarios.
For sure, Akka doesn't do it for you. I think one of the biggest yak shaves in setting up would be picking your partition strategy and making sure it works the way you intended. But, once you do it's fun to watch the metrics graphs move when you cut nodes. :)
> This is similar to what .NET developers are used to, since regular objects are also not destroyed when a method throws an exception, and the caller is able to handle the exception.
Yeah supervision can be a bit weird to explain properly.
It all goes back to that first point though; Orleans is a very guided implementation and has very nice, C#-like bindings. Akka is in my view (Akka.NET project contributor, have also written some frameworks and in-production business apps using) more of a 'Toolkit'. You can see this in the various modules that result from it, such as Akka Streams, Spray/Play. Lagom, etc. Use Orleans if you want to write distributed code in C# quickly and within it's constraints. Use Akka if you want to write distributed code or just a quick and dirty Message-passing Scheduler/kernel.
Earlier quoted context omitted.
It’s true even with distribution, see e.g.: http://erlang.org/faq/academic.html#idp33052176 http://erlang.org/pipermail/erlang-questions/2017-September/...
Huh. Never actually looked into HOW it worked in erlang, but basically it looks like it works the same way as Akka/AkkaDotNet; VM skates on top of the underlying transport's ordering guarantees. For a long time I was curious how Akka Artery preserved message ordering for it's 'dedicated large message' lane. in short it really just means you are dedicating a specific TCP or Aeron connection dedicated to those actors,…