HN user
mitchellnordine.com
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.
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.
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/
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.
Co-creator of nannou here, the project is indeed named after this track :)
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 :)
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].
Happy creating!
[1] https://github.com/nannou-org/nannou [2]: https://docs.rs/nannou
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.
I tend to use petgraph[1] when I need a graph-like data structure (the only time I've needed cycles). Super fast, distinguishes `Node`s from `Edge`s, lots of useful items for different kinds of traversal.
This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand.
edit: This is not counting FFI though.
That particular type is an Iterator over two HashSet intersections zipped together. I'm looking forward to getting rid of it!
Hopefully this is doable! I believe Jeremy's currently having a go at getting a build script working that will:
1. check if PA is already installed 2. if not, will download and install PA.
The pull request is open and is here if you(/anyone) want to check it out / comment / contribute:
I know what you mean.
I've talked with the author of the PortAudio bindings and we're planning on including a static lib with the repo instead (along with a cargo build script), so that should hopefully make it as easy to use as any other crate.
The only reason I began development on this is because of my own use case in which this style of UI suits perfectly. It suits so well in fact I'm entirely abandoning the classical retained UI which I've been using exclusively so far. I'm not claiming that this style is perfect for every or even most use cases, however from my own humble, limited experience I'm yet to come across a use case where I'd prefer to go back (I'm well aware that these probably exist).
Re pixel positions: Tooling is planned for easier widget placement... As I mentioned in the article, the project has barely had three weeks worth of work poured into it - perhaps it's best not to try and declare the project as useless when it's barely even out of the womb ;-)
Yes! this is one of the first links that introduced me to the more promising side of imgui - Conrod probably wouldn't have taken this direction without this intro.
- re layout: yes, at the moment there's a widget_matrix which can help with positioning, but I'm also keen to add slightly more friendly functionality into the ui_context: i.e. uic.add_widget(direction, padding, |position|{ /* widget::draw... */ }) or something along these lines. I'm totally open to other suggestions and inspiration too :) - re draw: this function is actually the only instance of code required for the widget (hence the "immediate-mode"ness), so I'm not too sure what else could be abstracted away (other than some args)!
I was wary of this when we had first started the project. Originally I had planned to just go ahead and start a classic retained UI - the idea of trying to structure a widget lib without widget structs/classes sounded incredibly painful... however after watching some vids and actually having a go myself I'm realising just how wrong I was.
A handy breakthrough in my case was to use Rust's algebraic data type to store each individual widget state within a single container in the UIContext. This is akin to "caching" the state of every widget in one place with a process that is invisible to the user, rather than requiring the user to instantiate large number of objects and work out where they will store widgets, canvases, etc. This approach also makes it really simple to only access certain parts of the state depending on what is needed via Rust's pattern matching and destructuring. I'm yet to come across any kind of widget that is more difficult to store state for than it is in a retained UI (it's even easier for the user of the lib as they don't have to think about it) though perhaps I'm naive in my early days!
All of the widget examples that you have given are already in the plans, I might as well just implement them and do another Show HN instead of rambling in the comments :)
I'm trying to OS what I can in another PistonWorks project called rust-dsp
https://github.com/PistonDevelopers/rust-dsp
It only has a basic DSP-chain atm on top of a PortAudio IO callback, but hoping to contribute some synthesis, sampling and effects work soon! Especially now I have some widgets to design instruments with :)
Yeah you're right, I was lining myself up for this one :-) There are plans to merge the first three args, merge the dimension args into a Shape enum and more. Still early days with lots of refining to do!
Absolutely love this rusty community. It's refreshing being surrounded by so many people consistently passionate about the language and its potential. Really looking forward to what this turns into!
The text I was reading scrolled off the top of the page as I was reading it. Also, I found the scrolling kind of distracting. Though perhaps it's not meant to scroll so fast at all?
Edit: This was on the latest Chrome, on MacOS10.9.2 btw.
...due to the "exponential" rate of progress of science.
I don't remember any great futurist referring to the "exponential rate of progress in science", but rather the accelerating advances in regards to information processing technology specifically.
You might find this interesting, just came across it today!
Unofficial Google Music API in Python, quite well documented. http://unofficial-google-music-api.readthedocs.org/en/latest...
About to get started writing a little script that will take care of synchronising my library with my google music one, and automatically uploading those that it can't find a match for. A few of my friends also use it, so I was also thinking of making a little tool that would allow us to compare our libraries and show us what each other are missing etc.