status of the project and functional programing in rust ?

[milibopp]

status of the project and functional programing in rust ?

[milibopp]

Oh, well, I would not say, functional programming in Rust is dead. Quite the contrary.

About this project: I am not actively working on it, but I am happy to take pull requests. The reason is that I have not had a real use case for a while. That said, in its current state the library by itself is definitely usable. I have a bunch of thoughts on how to take things further, even though I may not be implementing them any time soon.

For instance, when I started building this, there was no mature ecosystem for asynchronous IO, futures and stuff. This has changed and it is definitely something that I would build on top of, if I were to start over. The current internals are not exactly zero-cost, as lots of virtual dispatch and boxing is used to make things easier to handle. So using zero-cost futures, there is probably some room for improvement in terms of performance, as well.

Also note, that I have employed a global lock to keep things deterministic, which obviously conflicts with parallelism to some extent.

These principal considerations aside, the most difficult issue from my point of view is, that the graphics ecosystem in Rust does not really provide a lot of purely declarative UI components. Lacking such tools means it will always be a lot of work to integrate it with existing graphics frameworks like Glium, gfx or whatever you are using.

If somebody were to build a fully declarative 2D/3D rendering system in Rust, that would be pretty awesome.

Note, that there is carboxyl-window, which was an attempt to integrate windowing into carboxyl using Glutin. (Not recommended to use it, though, as I have barely been able to keep it up-to-date.)

There is elmesque for simple 2D graphics, but I do not think that this is maintained any more either. For 3D graphics, it is even more difficult. For comparison, on the web there are lots of virtual DOM abstractions on top of the browser's imperative DOM model.

Graphical user interfaces are not the only legitimate use case, of course, but it seems to be the most obvious, as it clearly requires an application to be stateful.

[GunpowderGuy]

since the development of this project languished , more experimental frameworks have emerged

[GunpowderGuy]

at least is trying to emulate the brand of functional programming elm declared itself ; while others claim to be inspired by the language shortly before that ( which was basically a superset of its current form but capable of frp , although not usually used that way )

[GunpowderGuy]

Its creators claim that the "elm architecture" makes for a simpler runtime , code maintenance and mastering of the language and relm's ( rust library ) devs , that it interacts nicer with non functional code ; however others argue that the benefits stem from frp not having been done properly

[GunpowderGuy]

i think that last bit is at most only half true ; what does worry me is simplicity may come at the cost of composability ( frp can even be used as an alternative to ecs )

[milibopp]

I was not aware of relm, thank you for the hint.

I think the motivations there are a bit different. Whereas Elm/relm intends to be a complete UI framework, carboxyl is only raw FRP. Of course, I have been toying with architecture similar to Elm's on top of that, see benzene. (Just a very small experiment, please don't use it.) My experience was that it appears much harder to find an Elm-like abstraction for the continuous notion of carboxyl's signals. At least my impression was that I failed at that.

As a conclusion, you could ditch the continuous signals altogether and go for something simpler like Elm – in this case carboxyl in its current state would be a bad fit and as Elm's evolution shows, FRP itself is not even required. Alternatively, keep the complexity but then composition has to happen at the stream/signal level.

I have been using Cycle.JS as an architectural guideline, which is more difficult to grasp, but also transfers much nicer to continuous signals. It may be worth a look, if you want to use FRP as an alternative to complex systems like ECS. Performance-wise there may issues with carboxyl there. (None that I am aware of, but anyway have been quite excessive with cloning in carboxyl.)

In the end, it really depends on what you want to achieve. I see it as an interesting experiment that provided some learning about event architectures, but I have yet to see how these things turn out in real-life usage.

[GunpowderGuy]

By looking at projects being made with elm , I wrongly got the impression that signals were necessary for composition , but " vanilla " functional programming is enough , isn't it ?

[milibopp]

Yes, that is pretty much the point. There are some things that get a little weird that way (like using ticks for continuous animation). But overall, the architecture will end up being much simpler, which may be worth forgoing the ability to express complex animations & interactions elegantly.

[GunpowderGuy]

Other advantages such as not having to recompute data can be covered by memoization and event handling , by subscriptions or ( not sure if i know what i am talking about ) clever use of futures ?

[milibopp]

Uhm… when you start doing subscriptions, you are already in observer pattern territory, in which case FRP is the more sensible approach, as the observer pattern has a lot of drawbacks – which is a key motivation for using FRP. I guess the whole point of the Elm architecture was to identify a common architectural pattern, make that the default and remove the fluff around it. But if you want more details on that, it's probably better to reach out to the Elm community. ;)

[GunpowderGuy]

@aepsil0n i have already tried asking the elm community ; most of them use the language mostly for gui and puzzlingly many game-devs use ecs with ( i didn't know this was possible or necessary with functional programming )

[milibopp]

Closing, as there does not seem to be any open issue here.