FoundationDB logo

Last week, Wired ran an article called “What Happens When Apple Buys a Company You Depend On?,” which tells the story of how FoundationDB was acquired by Apple and subsequently threw their customers under the bus.

This is a developer’s worst nightmare. The realization of their worst fears when they choose a technology to build on top of.

Imagine yourself in this scenario: you took a chance on a product or open-source project, invested time with your team to learn what it is and how it works, and figured out to use it to further your mission. You counted on it to be reliable, and wanted it to power your systems for years to come.

And then it gets abandoned, discontinued, or re-licensed, and all your work that depends on this technology is lost.

Anyone whose production systems depend on FoundationDB today is going to have to spend real dollars and real hours replatforming off of it. That’s time and money they could be investing into new development, but instead those resources have to be used to recover. That sucks.

How else could this acquisition occurred, assuming that Apple has no interest in continuing work on FoundationDB?

Akka.NET - a C# port of Typesafe's Akka project

Today the Akka.NET project hit a massive milestone and became code complete for version 1.0.

This puts us on track to hit the v1.0 public release within the timeframe that we (the core Akka.NET contributors) committed to back in February.

“Code Complete?”

This means that every major feature and every public API has been completed and finalized in preparation for release.

1.0 is the release in which we’re going to shed Akka.NET’s -beta tag and commit to preserving these APIs long-term, so this is a major deal. More than a year’s worth of production usage, discussion, and designs have gone into these APIs.

A lot of carefully considered choices and designs go into each Akka.NET release, but this is the most important one we’ve ever done.

Here’s what will be included in the stable release of Akka.NET v1.0, for both Mono and Windows:

  • Akka.NET Core
  • Akka.FSharp
  • Akka.Remote
  • Akka.TestKit
  • Akka.DI (dependency injection)
  • Akka.Loggers (logging)

We will be committing to the v1.0 APIs for long-term, production use.

Can I Still Contribute to 1.0?

Yes! You can! We’re no longer accepting public API modifications or additions, but here are some areas where we’re still actively accepting and encouraging contributions:

  1. Bug fixes;
  2. Spec verification;
  3. Enhancements (don’t affect the public API);
  4. Documentation;
  5. And work on modules that aren’t shipping as part of V1.0, such as Akka.Cluster and Akka.Persistence.

If you want to start contributing to Akka.NET, join us in the Akka.NET Gitter chat. We’re a friendly bunch!

Timeline For V1.0 Release

We still have some work we do before we release the v1.0 bits - mostly documentation (oh...

Today we’re going to learn about one of the really cool things actors can do: change their behavior at run-time!

This capability allows you to do all sorts of cool stuff, like build Finite State Machines (FSM) or change how your actors handle messages based on other messages they’ve received.

Today, we’re going to cover how to make a basic FSM using switchable behavior. We’ll go over advanced FSM approaches in a future post.

Let’s start with a real-world scenario in which you’d want the ability to change an actor’s behavior.

Real-world Scenario: Authentication

Imagine you’re building a simple chat system using Akka.NET actors, and here’s what your UserActor looks like - this is the actor that is responsible for all communication to and from a specific human user.

public class UserActor : ReceiveActor { private readonly string _userId; private readonly string _chatRoomId; public UserActor(string userId, string chatRoomId) { _userId = userId; _chatRoomId = chatRoomId; Receive<IncomingMessage>(inc => inc.ChatRoomId == _chatRoomId, inc => { // print message for user }); Receive<OutgoingMessage>(inc => inc.ChatRoomId == _chatRoomId, inc => { // send message to chatroom }); } } 

So we have basic chat working - yay! But… right now there’s nothing to guarantee that this user is who they say they are. This system needs some authentication.

How could...