Rebar is a graphical dataflow language with Rust-like semantics (ownership and borrowing) that I have been working on as a side project. Rebar represents programs as diagrams containing nodes (expressions) and wires (variables/values); nodes have a natural execution parallelism when they are not explicitly connected with wires. As in Rust, variables can have ownership of values or be references. Here is a simple example that sums numbers in a loop:
Here's an older post with more of an overview of how Rebar works, although it's more aimed at a LabVIEW programmer audience.
Rebar is implemented as an addon to the LabVIEW NXG programming environment (as such, it's only available on x64 Windows platforms). The recently released LabVIEW NXG 5.0 Community Edition is free to install for non-commercial, non-academic use, and Rebar 0.2.0 is compatible with LabVIEW NXG 5.0. (More information about how to get LabVIEW NXG 5.0 and Rebar 0.2.0 is linked from here.)
I've refrained from posting about this in Rust forums before, because I figured it was mainly of interest to people who would already have been using LabVIEW. Now that there's a free way to install it, I'd love to hear what Rust users think.
One of the things I think is interesting about Rebar from a Rust perspective is the way the borrowing system works. (Some of this is explained in the post linked above.) Many nodes (expressions) take values by reference, but they will happily create an implicit temporary borrow from an owner variable input. To create a reference to a variable explicitly, though, you have to give up using that variable temporarily--at the point where you create the reference, the original variable in unavailable. In turn, you have to relinquish the reference (or other variables with the same lifetime) to "get back" the variable. Thus, it becomes harder to get into situations where a reference outlives the variable that it points to, although not impossible. This is contrast to Rust, where a variable and its references can be simultaneously live in the same scope, and borrowck has to ensure that usages of them are not in conflict.
Anyway, hope this is interesting to someone!
