mitchmindtree
Joined 12 years ago
Karma
338
Submissions
34
Member since
Mar 18
mitchellnordine.com
View on Hacker NewsRecent submissions
Comment · 3 years ago
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!
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
On the topic of SSGs, is anyone using styx[1]?
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.
[1]: https://styx-static.github.io/styx-site/ [2]: https://github.com/styx-static/styx/
Comment · 5 years ago
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.
Comment · 5 years ago
Co-creator of nannou here, the project is indeed named after this track :)
Comment · 7 years ago
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 :)
Comment · 7 years ago
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 :)
Comment · 7 years ago
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 :)
Comment · 8 years ago
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].
Happy creating!
[1]: https://github.com/nannou-org/nannou [2]: https://docs.rs/nannou
Comment · 9 years ago
We put our lives in the hands of code written by humans every day, e.g. cars, planes, trains, etc.
Perhaps the permanence of executing solidity contracts will at least motivate some safer, more secure practises, in the same way that the permanence of death does when programming vehicles that carry human lives.
It would be cool to see APIs for compiling Solidity contracts from safer languages with more concise type systems like Idris[1]. That said, I haven't had a proper dig into Solidity myself yet so it could very well offer some of these features. I'd love to hear some experiences from devs who have written a significant amount of code in it.