1,556 karma · joined September 10, 2010
https://efnx.com https://renderling.xyz https://zyghost.com https://github.com/schell
[ my public key: https://keybase.io/schellsan; my proof: https://keybase.io/schellsan/sigs/Jx6C8Hba5v_cbBw0oJTrLxSFtKRfCaYOC1kNl0tlYAk ]
Arguably not a “toy”, but it’s interesting to think about.
For the most part all I need is an address. That’s it. Then it takes a couple minutes to transfer - done!
Disclaimer, I currently work at a zcash corp.
The hard part is that for day to day things you still need an on ramp and off ramp, but that is changing as merchants accept crypto directly.
I want to make games, but I know how much time that takes, so I understand that to make something cool I need funding to be able to focus on that cool thing. Crypto can be a tool in this case, and I personally would prefer mining to watching ads.
Hackers are great and analyzing systems and figuring out what they might support, despite the original designer's intentions.
(Edit: added stuff in parens)
(Edit) And they should be setting their own prices!
Joking aside, the present always has a tangential future that never comes to be. Right now the current zeerust is “AI and robots doing everything”. Continuing to have humans do it is good enough.
In what kind of irregular democracy is this practical? Not arguing, just curious.
As a professional Rust developer, I don’t find I do this. I occasionally think of those things. But I do remember a short adjustment period when I was learning Rust that I would get frustrated by the borrow checker. Of course, that’s it doing its job!
Yeah, totally. I have those same feelings. It's hard to fight it because `.lock()` and friends do _feel_ heavy!
Unless that RwLock is in contention to get acquired every frame I doubt it will add anything significant to the frame time. Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust.
Furthermore- UI updates are usually all run from the same single thread, so it’s unlikely the other widgets could even contend for that lock! You might be able to get away with the lock approach and you may even be able to use Rc<RefCell<_>>, which would get a little speed up.