Hacker News Reader

Comment by jll29 | Hacker News Reader

I wonder if creative people can be bothered to learn Rust, or perhaps an easier path to adoption could be a simple DSL.

OpenFrameworks[0] is quite popular for creative coding even though it's written in C++ - framework is actually pleasant to use. If you want to do some creative coding on both iOS and Android you don't have many options. If you want to use sensors (cameras, microphones, gyroscope, accelerometer, etc) and e.g. process video stream at 120fps you have even less choices.

Sadly OpenFrameworks development seems kind of stalled. Nannou + Rust could be a good or even better alternative:

1) painless cross-compilation to different platforms

2) plugins installation via cargo

3) more up-to-date plugins as tiny wrappers around CPAL [1] (audio I/O), nokhwa [2] (video i/o), opencv-rust[3] (video I/O and processing), rust-sdl2 [4](IMU sensors + game controllers), egui [5] (immediate mode gui + plotting)

4) better errors and more modern language

[0] https://openframeworks.cc/ [1] https://github.com/RustAudio/cpal/ [2] https://github.com/l1npengtul/nokhwa [3] https://github.com/twistedfall/opencv-rust [4] https://github.com/Rust-SDL2/rust-sdl2 [5] https://github.com/emilk/egui

Nanou still has quite a bit to catch up with openFrameworks API surface though.

Also those "plugins" are kind of limited to compile time, not really what plugin infrastructure is about. Nothing that can be dynamically loaded into an existing installation.

At very least I would expect something like DAWs or COM make available.

They can! I watched an interview with the makers of this framework and they're artists themselves that learned programming to make art.

Rust can run fast and thus is attractive for this kind of thing.

The quick run speed is great for shortening the feedback loop. I've had great experiences with Lisp-style environments for that reason, and the language is much higher level than Rust while still offering good performance. I've mainly used Quil, the Clojure wrapper around processing: https://github.com/quil/quil

I'm surprised that this feels more verbose than libcinder, which already pushes beyond a lot of creative coder skill sets. I wonder if it does need another pass getting a DSL together or some abstraction toolkit to get it marrying up closer to the processing experience.

I did. although simpler languages like Python and JS were easier to get your ideas on the screen quickly, they are too resource intensive. Large and complicated pieces become too slow to work on as time goes on, and you have to either get better hardware or use a faster language such as Rust.

Yeah, I don't want to dismiss this project out of principle, because it's cool! But I'd still recommend software like Touch Designer, or Notch (or some free alternative) for creative people. Fleshed out IDEs with both code and visual editors (and preferably with good support for a ton of peripherals).

Try creating some of the more complex examples from "nature of code" in a node-based environment.

The networks you get are huge. And understanding them, after a month e.g., becomes tedious at best.

The creation may seem more artist friendly but understanding/modifying are very much less so when a certain complexity threshold is reached.

Code is simply easier to read when you reach that aforementioned threshold.

Writing code is also a different experience than using a node-based editor but that's more philosophical than pertaining to what is better when.

My experience is mostly with Houdini in VFX.

Whenever I have to touch a complex node graph, my own after a while, or someone else's -- the more nodes just containing plain VEX or Python code are in there, the easier it is usually to understand (vs someone making a sub network with another 30 nodes for what could be expressed with 10 lines of VEX).

As a programmer and visual thinker, I always wish there was some kind of hybrid approach. There's no reason standard function calls can't be visualised as nodes, while keeping each function as pure code.

Possibly it would work best in a functional language like haskell or elixir.

Visual Languages also allow to write modular code, by packing complex stuff into modules and libraries, maybe people try to stop doing everything on a single diagram.

That would be, for example, "Processing"

https://processing.org/

The borrow checker is like a straightjacket. Creative types won't like it.

Also, the bureaucracy.

Better use a language with surprises, like C++.

Probably not, but it can be bypassed at the framework level.

Having reasonable compilation errors is tempting.

I have creative background, always feared and never learned C++. Maybe if one has years of OOP experience, feeling can be different, but for me, borrow checker felt straightforward.

There could be some complicate cases of trait bounds using some 3rd party libraries. However one will hardly encounter that while playing with Nannou.

Having rust-analyzer is also huge plus.

Au contraire, this video discusses Jack White's opinion that creativity is only properly unleashed under restriction.

https://www.youtube.com/watch?v=tMHCJ8GCfaU

Reply on news.ycombinator.com