reubenbond

7 ms·

1.
by reubenbond 2y ago
Would GC.TryStartNoGCRegion work for you? https://learn.microsoft.com/en-us/dotnet/api/system.gc.tryst...
2.
by reubenbond 3y ago
We have a section in the FAQ about it: https://learn.microsoft.com/en-us/dotnet/aspire/reference/as... In short, these are complimentary things. Think about it like this: you use aspire to define the pie
3.
by reubenbond 3y ago
We should chat more about Reminders v2 - I want to learn more about what you'd like it to provide. Can you comment on the issue ( https://github.com/dotnet/orleans/issues/7573 )? If you'd like to see
4.
by reubenbond 3y ago
There were a bunch of new features added to Orleans in the past year, including Live Grain Migration, IAsyncEnumerable support, Cosmos DB & Redis providers. I think workflows (durable async/await) are more useful than Reminders v2
5.
by reubenbond 3y ago
Which systems use Calvin-like protocols?
6.
by reubenbond 3y ago
> Anything but RabbitMQ. Would you mind elaborating on this? I'd be happy for others to chime in with their experiences/opinions, too.
7.
by reubenbond 3y ago
Not the same, but this reminds me of the Epoch Protection Version Scheme discussed in this paper: https://dl.acm.org/doi/fullHtml/10.1145/3533737.3535091 EPVS is used in Microsoft FASTER, a KV storage engine
8.
by reubenbond 3y ago
I used it to test an idea I had to implement the Fast Paxos optimization on top of CASPaxos and it was quite useful for that: https://github.com/ReubenBond/fast-caspaxos (the code is bad, it's just an experiment)
9.
by reubenbond 5y ago
try virustotal.com
10.
by reubenbond 5y ago
Coyote is a great tool/library from Microsoft for testing large numbers of schedules in .NET programs: https://microsoft.github.io/coyote/
11.
by reubenbond 5y ago
If task A & B perform IO (eg, a DB call) and the alternatives are running them sequentially on one thread or running them concurrently (via async/await) on one thread, then running them concurrently can both decrease end-to-end lat
12.
by reubenbond 5y ago
> Consider that the minimum grain of a Task.Delay is 1 millisecond. The minimum here is contingent on a few things. The API can accept a TimeSpan which can express durations as low as 100ns (10M ticks per second: https://docs.
13.
by reubenbond 5y ago
The Opus OpenSubtitles corpus was very useful when I was creating this Chinese-English dictionary app: https://github.com/ReubenBond/HanBaoBao . The tool which creates the dictionary database aggregates several sources,
14.
by reubenbond 5y ago
Given how Ray "provides [...] exactly-once semantics" for its actors, you could draw similarities between it and workflow-as-code frameworks such as https://temporal.io . The way that Ray splits up actors and tasks look
15.
The Curse of the A-Word(docs.temporal.io)
1 points by reubenbond 5y ago|0 comments
16.
by reubenbond 5y ago
> I was watching a talk from Microsoft on the topic where they would refer to actors as “cloud native objects” and the model itself as an ideal way to do OOP on distributed systems. The marketing feels a little cringe at first but the me
17.
by reubenbond 6y ago
The Raft paper is there. It's the first paper under the "Expository papers and blog posts" section
18.
by reubenbond 6y ago
Orleans and Service Fabric are different. Orleans has been running in production for some time now and is actively developed on GitHub: https://github.com/dotnet/orleans . Teams inside Microsoft run it on top of Service
19.
by reubenbond 6y ago
Have you seen Orleans? https://github.com/dotnet/orleans
20.
by reubenbond 6y ago
> 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? - if .NET Orleans runs fine on Kubernetes, why is there a
21.
by reubenbond 6y ago
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 t
22.
by reubenbond 6y ago
I think if you look at the consistent development history, you can use that as an indicator. Internal teams host it on Kubernetes (Linux), Service Fabric (Windows), and other places. The "Orleans at Microsoft" talk from August cov
23.
by reubenbond 6y ago
No, Service Fabric Reliable Actors are based on the Orleans API and model
24.
by reubenbond 6y ago
There is a new package which adds improved Kubernetes integration and fixes the issues you mentioned specifically. It's in beta right now, but we expect a stable release soon. Feel free to contact me and I can help you with running Orl
25.
by reubenbond 6y ago
There are developers using Orleans with F#, so it does work. It is not as nice of an experience as it ought to be, though. For example, it requires a dummy C# project to hold the generated RPC/serialization code. PRs to improve the exp
26.
by reubenbond 6y ago
> 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 sen
27.
by reubenbond 6y ago
If the link is being updated, I think the github repository provides a much better overview: https://github.com/dotnet/orleans/
28.
by reubenbond 6y ago
That's a good question. I wasn't around at the time the project was formed. At that time I was working on Microsoft's internal metrics system. Years later, I became involved as an external contributor (I had left MS) and even
29.
by reubenbond 6y ago
My opinion is biased, as a core developer, but I do not think it's packed full of design patterns. Orleans and the core team are relatively unopinionated on design patterns that developers employ. I'm much more concerned with deve
30.
by reubenbond 6y ago
All communication in Orleans is asynchronous, similar to communication in gRPC, so in .NET world, you're using async/await with methods that return Task/Task<T>/etc. The boundary there is hopefully apparent: async

More ›