openFrameworks & Rust

Hi OFers!

##TL;DR

Has anyone been experimenting with an OF-like project in Rust? Or perhaps even an experimental port?

If so, is there any chance that you would be interested in open-sourcing your progress so that others may contribute?

On the other hand, if noone has yet made a start on this, are there many folks who would be interested in seeing something like this started? Is this sort of experiment something that OF itself would be interested in endorsing?

FWIW, I’m aware of at least a couple other OFers who would also be interested in investing some serious time and effort into something like this.

##Motivation

I’ve been a massive fan of openFrameworks for a while now and have used it in quite a few projects, including commercial, personal and OS. It was my first introduction to systems programming and C++ and was also my first introduction to the awesome potential of creative-coding in a high-performance environment. I owe the OF crew so much and would not be where I am today without them - thank you for all your work!

More recently, I’ve become a big proponent of the Rust programming language. It solves a great deal of the issues that have frustrated me about C++ for a long time (package management, linking, sum types, safe memory management, etc). Over the past few years I’m finding myself almost always choosing to use Rust over C++ if I can, provided the crates I need exist or I have enough time to roll them myself.

My biggest issue with Rust currently is that there are no great creative coding frameworks around which artists and creative tool-makers can consolidate all their efforts. Under a project like OF, artists could settle and agree upon a specific set of window, graphics and audio backends, making it easier for folks to quickly assemble and share tools and projects and focus their work upon a common foundation. E.g. windowing could be handled by something like winit or glfw, graphics tools could be built on top of something like glium or vulkano, audio tools and graphs could be built upon something like CPAL or portaudio, etc.

One of my first ambitions when first getting into Rust was to attempt to create an openFrameworks-esque crate for these reasons. However, I was still new to the language at the time, the ecosystem was quite immature at the time and the task seemed overwhelming to tackle alone, so I abandoned the effort after a short while.

Now that the ecosystem is considerably more mature than it was when I started a few years ago, I’ve been considering starting work again on a creative coding framework. However, if someone has already made a start on a descendant of OF I’d much prefer to contribute to that if they would be at all interested in opening their work to other collaborators?

Cheers!

6 Likes

I also would love to see something like this happen. Rust is an amazing programming language with beautiful and easy to understand syntax. I would be more than happy to help contribute to a Rust oF port, taking inspiration from p5.js we could call it oF.rs…? :stuck_out_tongue_winking_eye:

Interested to see who else on here has been dabbling with Rust yet? I remember speaking to @arturo a few years ago at resonate about some of the Rust projects he has been doing…

1 Like

Rust has also sparked my interest, it seems like a great succession to application where you would have normally used C++. If openFrameworks would exist for Rust that would be tremendous. With all the effort of translating between the two languages might it be a possibility at some point to have a wrapper that can be maintained with a lowish effort as opposed to a complete port?

1 Like

I found these. Maybe no need for glfw?



1 Like

Thanks for posting these!

I have used glutin in both personal and commercial projects and it has worked out well. Some parts still need some ironing out (see the issue tracker) however it is already capable of most of the features that one would require for something like this either way. You can have multiple windows, shared or separate GL contexts, control over window decorations and transparency, etc. I think it is a great candidate for a project like this for a few reasons:

  • It is pure rust, meaning folks who are already contributing to the hypothetical rust-OF can more easily contribute upstream if they come across missing features or bugs.
  • No need to download or install any third-party C libraries on the system. When used as a cargo dependency, cargo will automatically download and build it without any other work by the user required.

It should be noted that glutin is a thin wrapper around winit which I mentioned in my OP. winit provides the cross-platform windowing API while glutin provides the Open GL context on top.

The author of glutin also designed glium:

Elegant and safe OpenGL wrapper.

Glium is an intermediate layer between OpenGL and your application. You still need to manually handle the graphics pipeline, but without having to use OpenGL’s old and error-prone API.

While glutin only provides a portable GL context, glium provides a full, safe API around the GL pipeline. If we decided to start with Open GL (instead of say Vulkan), I think I’d prefer glium for a project like this over gfx due to glium’s simplicity and approach-ability, having tried both before. glium focuses solely on providing a nice API around the Open GL pipeline, while gfx is more abstract and aims to provide a generic API over different graphics backends. While I admire the ambition of the gfx project, it was significantly more complex to use in my experience and still requires writing back-end specific shaders, etc despite their effort to generalise over different backends. This may have changed over the last year though - it has been a while since I’ve tried seriously using it.

Alternatively, if we were to place our chips on Vulkan instead, the same author is currently in the process of refining their vulkan crate called vulkano which sounds promising:

Vulkano is a Rust wrapper around the Vulkan graphics API. It follows the Rust philosophy, which is that as long as you don’t use unsafe code you shouldn’t be able to trigger any undefined behavior. In the case of Vulkan, this means that non-unsafe code should always conform to valid API usage.

What does vulkano do?

  • Provides a low-levelish API around Vulkan. It doesn’t hide what it does, but provides some comfort types.
  • Plans to prevent all invalid API usages, even the most obscure ones. The purpose of vulkano is not to draw a teapot, but to cover all possible usages of Vulkan and detect all the possible problems. Invalid API usage is prevented thanks to both compile-time checks and runtime checks.
  • Handles synchronization on the GPU side for you, as this aspect of Vulkan is both annoying to handle and error-prone. Dependencies between submissions are automatically detected, and semaphores are managed automatically. The behavior of the library can be customized thanks to unsafe trait implementations.
  • Tries to be convenient to use. Nobody is going to use a library that requires you to browse the documentation for hours for every single operation.

That said it is a lot newer than glium, and although the author seems to be at the stage of refining the API and has a number of working examples, the README still contains this:

Warning: this library breaks every five minutes for the moment.

1 Like

Hi mindtree,

I can’t wait to start working on a framework like OF in Rust :slight_smile: Actually, I evaluated a lot of libraries currently available. For the time being I could image a stack like this:

  • windowing: winit / piston_window
  • gui: conrod
  • graphics: gfx-rs
  • audio: rust-audio / portaudio
  • midi: midir

There are several important components missing, like image processing (OpenCV wrapper), Kinect interface etc. But: all of the libraries mentioned above were used in small projects I did in the last couple of month. Trying out different things helped a lot to understand the potential but also the risk starting a big project like this :wink:

If you’re interested in the stuff I wrote so far, here are the links:

Looking forward!