Greg Egan's Permutation City is an all-time favourite. The combination of simulation, cellular automata, garden of eden states and Dust Theory blew my mind as an adult in the same way that the Matrix did when I was a kid. Very keen to check out this new work!
Yeah, I would really like to see `nix-env -i` recommended far less often, or at least with the caveat that this should only be for testing packages at the most. I still haven't found a good use case for it personally.
One of the big wins for Nix is its declarative nature (especially for reproducibility) and installing packages in an imperative manner like this just seems to put folks back in the same position as using pacman or apt-get. Please correct me if I'm wrong Nix-ers.
Having used NixOS as the main OS on my personal laptop for the past year or two (and loving it), I've only used `nix-env -i` to install a package once, and immediately regretted it after trying to add a different version of the same package to my main configuration files. This resulted in a conflict, which from memory required me to force reinstall the package again via `nix-env` but specify a lower priority so that it could be replaced automatically when enabling the package via my configuration files... A really strange experience that re-affirmed that nix-env is at least not for me.
For testing packages, I would always recommend `nix-shell -p <package>` as a preferred option. Just type `exit` and then you've left the shell, it's no longer in your PATH and there's no risk of conflicts.
It sucks that you ran into this, but also totally understandable. I think generally the community would consider the nix-env approach of installing and updating packakges an anti-pattern these days, but this certainly isn't obvious when reading through the docs.
> and installing packages in an imperative manner like this just seems to put folks back in the same position as using pacman or apt-get. Please correct me if I'm wrong Nix-ers.
It being similar to the other commands means we can use nix almost no learning curve, only having to know the equivalent commands. It's the beginner's interface, allowing you to get things done right away, and letting you postpone the complexity until you have need for the features/stability it provides.
For example, I originally started using nix because I needed a Java version not in Ubuntu's repo, and being able to say "just install it" instead of having to learn a whole new specification language is a massive benefit.
Yeah I’ve been running Nix on a home server for a couple years and using home manager on my MBP for just as long. The biggest challenge to learning has been all the examples that use nix-env -i.
Nix has a heavy learning curve and requires learning the language to feel comfortable. However, overcoming that hump is incredibly rewarding and allows for taming your system in a way that, for me at least, changed the way I look at composing software.
At mindbuffer[1] we've started using it for our recent art installations. The big benefits for us are reproducibility, ease of deployment, and the ability to collaborate on the composition of the whole system. I.e. rather than sharing a README of how to install things one by one and hoping each of us has followed it correctly, we just work on the same set of config files via a git repo (like we would any other code) and can be sure we're all on the same page as a result.
Very much looking forward to Nix 3.0 landing with all its UI improvements and flake support. It seems like these changes will go a long way to making Nix more accessible, and provide a smoother on-ramp to learning the language itself.
As a keen NixOS user, I love the idea of configuring my site with nix and embedding nix exprs in markdown. However, I'm unsure whether the project is still active, or if the whole thing was more of an experiment. The repo[2] seems a little quiet, but the documentation is extensive and great considering! I wonder if the author just considers it complete? Curious to here experiences from anyone who has had a play.
It is probably not the best term, but I'd say it is the term that caught on to describe the use of coding where artistic expression is the main intent. I think the wikipedia entry[1] is pretty accurate with respect to how it is used colloquially.
Woah excellent to see Embark partnering with the RLSL project!
As someone who does a lot of creative-coding contracts with lots of video, graphics and real-time requirements, RLSL has long been one of the Rust projects that excites me the most. The idea of writing graphics and compute shaders in Rust, a modern language with a decent type system, standard package manager, module system, etc, is very exciting. It makes a lot of sense that Embark see the potential in this for game dev too.
The ability to share Rust code between the CPU and GPU alone will be so useful. The number of times I've had to port some pre-existing Rust function to GLSL or vice versa is silly.
Obviously the Rust that compiles to SPIR-V will be a subset of the Rust that compiles to LLVM or WASM, but this still opens up so many doors for improved ergonomics when interacting with the GPU from a Rust program.
I've long dreamed of an API that allows me to casually send a closure of almost arbitrary Rust code (with the necessary 'lifetime + Send + Sync + SpirvCompatible compile-time checks) off to the GPU for execution and get back a GPU Future of the result. It looks like this may well become possible in the future :)
Hey kvark, I really appreciate all the work you're putting into the Rust graphics ecosystem!
Just fyi, we are closely watching both wgpu-rs and rendy and will continue to do so over the next couple of months. Vulkano has been a mission to use to say the least, maintainership is dwindling (most of the recent PRs are from us), and the Rust graphics landscape has changed quite a bit since we made the decision to use it almost a year ago. Both wgpu and rendy seem like strong contenders for the future of nannou's graphics, but we probably won't go down that road for a couple more nannou releases at least while we focus on some other areas.
We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
Also, I realise that wgpu is web-first, but I'd be curious to get your thoughts on its potential for use in native applications for installations and projection mapping - e.g. will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Anyway, we'll do another post soon about our thoughts on the future of graphics in nannou, just wanted to let you know you're on our minds :)
Delaying with decision to adopt Rendy or wgpu-rs is reasonable: both are still maturing, and are in the early adopter phase.
> We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
No, this would not ever be in wgpu (or feasible on top of WebGPU in general), since it's providing safety at lower level, and there is no way to get near-zero-cost there.
Saying that, I'm not sure what the bottlenecks of your use-case are. Do you plan on submitting a lot of different work on GPU, i.e. heavily use command recording on CPU (as opposed to relying on GPU instances), to the point of being sensitive to CPU performance? My expectation from a creative coding framework would be that zero-cost is not the foremost priority.
> will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Yes, I think this is already possible in wgpu-rs, although nobody tested multi-windows yet. In general, we put heavy focus on native usage.
Thanks for the kind words bjz, it means a lot coming from yourself!
I know you're busy with language design these days (and I would never stop you, I think what you are doing is some of the most important work there is right now!), but if you ever get the itch for some creative coding it'd be an honour to see you give nannou a shot and get your thoughts on what's missing, could be improved, etc :)
Josh (fellow founder) and I have been hacking on this over the past year and working on the foundational crates for much longer!
As lovers of the bullet-proof Rust vest and creative coding frameworks like OpenFrameworks and Processing we felt it was about time to merge the benefits of the two while attempting to apply some of the lessons learned by these predecessors.
While the library is certainly still in its youth we have been using it with great success in our recent commercial work and feel it is finally time to share it with fellow hackers and artists who might like to have a play or perhaps even join the project!
I'll be around to answer any questions for the next hour or two and then will try to make it back on tomorrow before we give the presentation at Protopixel in Barcelona.
I'd like to apologise in advance for the lack of HTTPS - the site is still fresh and we are in the process of getting it working ASAP.
If you would like to skip the announcement post and jump straight to the git repo see here[1]. If you are more curious about the API and would like to jump to the Rust reference, see here[2].
