paint-brush
Functional Reactive Programming in Rustby@andrew_lucker
2,478 reads
2,478 reads

Functional Reactive Programming in Rust

by Andrew LuckerMarch 21st, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

So, I’m a big fan of FRP for UI. I love to use it on the web. React and other frameworks sort-of follow FRP. For the Desktop, and specifically using Rust GUIs there aren’t much in the way of choices for this style yet. The language even has features that deter the FRP style or at least make it quite a bit harder.
featured image - Functional Reactive Programming in Rust
Andrew Lucker HackerNoon profile picture

So, I’m a big fan of FRP for UI. I love to use it on the web. React and other frameworks sort-of follow FRP. For the Desktop, and specifically using Rust GUIs there aren’t much in the way of choices for this style yet. The language even has features that deter the FRP style or at least make it quite a bit harder.

So what is FRP? In short, FRP is simply a declarative form of MVC. All rendering code is functional declarative. All Models are declarative. All data interactions are also declarative. The key is that there is no “glue”, that is all taken care of by using framework primitives.

Where this get’s messy is that no languages have simple solutions to bidirectional data-binding. Everything is dandy from the top-down, but when you look at React classes you will see all the boilerplate that is required to send data changes up the DOM hierarchy.

I’ve been playing with GUI components in Rust, and enjoy the simplicity of having no framework at all beyond an OpenGL context… maybe I should build my own framework, haha. For now I just want to build a game and play it, but the MVC mess that I’ve layed out for myself is sometimes hard to grasp. So, that is why I am looking at these FRP primitives.

Languages like Elm, which I am unfortunately not very familiar, do a good job of integrating and enforcing a proper style. Sometimes having fewer options is better. Trying to channel some of that into my Rust code I find that the ownership checks are very intrusive. I wouldn’t have any problems with this if it weren’t for the GUI libraries being so early in development. Most of the time the primitives there are slightly dirty with their data and basically nothing implements the Copy trait.

Without the Copy trait I can’t be sending data flying around or establish a good context without invoking the wrath of ownership and mutability constraints. So that is why I write my frustration. Don’t get me wrong, I love Rust, the ownership checks are making my code better, if not quite what I was intending for. In the future I will hope that some of the library primitives will play well with each other, and that may mean waiting until things hit version 1.0.0. It all seems so new.

I guess this is what it means to claim fertile land. You need to plant the seeds yourself or nothing will grow.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!