Is there a plan to release the Flow language and SDK?
All the flow tooling is there in the foundation repo. The core is the so called “actorcompiler”, a transpiler that reads Flow source (.actor.cpp files) and writes out generated C++ (.g.cpp files) that is processed by a normal C++ compiler during the build process. There is also a “flow binding” for the FoundationDB client so you can write layers in Flow if you want.
Documentation is… sparse.
1 Like
Thanks for the quick response… from surfing the FDB docs, I couldn’t determine that Flow was included in the macOS package.
Some sample code would certainly help at some point — I realize that you FDP Engineers have a lot on your plate (a good thing) and your priorities are different than mine (also a good thing).
As a potential FDB user and protagonist, I want to be sure that it is worth the investment of time and $.
I’ve completed my initial read of the source code (awesome) and it looks like all of the flow components live here:
I’m very interesting in Flow, but I found that it’s be complied by C#.
Do you have a plan to build Flow as an independent project ?
The transpiler is written in C#. There’s no need for a .net runtime at run time.
I doubt you will get much interest in rewriting the transpiler in a different language, though of course it would be feasible.
Eventually I hope C++ gets an adequate continuation passing transform built in. I haven’t examined the coroutines proposal to see if it’s good enough - the devil is in the details.
Porting the Actor Compiler project to target .NET Core looks easy enough, and would make it more usable on Linux and MacOS (no need for Mono), but would require installing the corresponding .NET Core SDK (on Windows as well).
I don’t know a log about .NET Core, but if the actor compiler were ported .NET Core, would that make native binaries, then? Presumably, you would you still need mono (or some equivalent tool) to compile the actor compiler itself, though, right?
The .NET Core SDK is available on Windows, Linux, MacOS (and probably other BSD flavors) and contains the compiler and all the build toolchain required, so no need for Mono (to build or run .NET code).
Also, you can build “platform neutral” code that must be run with the .NET Core runtime with the same command dotnet SomeApp.dll ...args... on all platforms, OR you can decide to build a platform-specific versio and targeting a specific architecture, which will give you a windows .exe, macos native app or linux executable (that does not require to install the .NET Core runtime to run).
Though if you need to build the ActorCompiler on the build machine anyway, you would already have the SDK installed and so there would be no point in building platform-specific binaries.
Here is the quick start guide for compiling and running a hello world on linux: https://www.microsoft.com/net/learn/get-started/linux/rhel
For the Visual Studio SLN, I think the only tricky part will be how to change the MS Build Task to invoke dotnet ActorCompiler.dll ....args... instead of ActorCompiler.exe ...args....
I don’t know what other IDE you are using to develop on Linux or Mac, but the changes would be similar (probably as simple as replacing “mono” by “dotnet run …” and “mcs” by “donet build”… I think most people use VS Code on non-Windows OS to build, debug and run .NET Core apps.
I have created a proof of concept in https://github.com/apple/foundationdb/pull/499 that only works when building with Visual Studio (and it will break the linux build because old version of Mono may not support the new csproj format)
As you can see, there is not a lot of changes. The main change for the build scripts is running “dotnet actorcompiler.dll” instead of “actorcompiler.exe”.