I wrote this in a review I believe, but this is one of the most comprehensive introductions to a good 80% of what could be considered a high performance computing education. It's extremely well written, in the weeds, but not lost in them. If you've done heavy atomics and or locks in C or C++ or with Fortran libraries, this will help show you how rust prevents so many footguns at compile time.
My thought has always been that the ratio of lifetime to any given sublifetime unit of time is always increasing, leading to a change in relative experience. But if you focus on the fact that a second is constant, you always have the same amount of time right now.
I love this and I'm super glad it's being developed, but I think I'd have to break my arm or hand (or have severe RSI) to really dive in. The startup cost seems high, mentally speaking.
This is great, the amount of boilerplate it takes to write an iterator is a bit cumbersome right now. Looking forward to see how this fares as it moves towards stable.
Let's say you wanted to run some python code that was written and test it against some C/C++/Rust for accuracy of some sort (numerical, lexicographical, etc). In the old way you would have to fire up multiple processes to do that (like OS level processes) but now you can have your multithreaded compiled code running in threads and your multi-GIL'd interpreted code running all in one process and comparing their results in the `main` of your C/C++/Rust. That's a contrived example, but the issue was that a single GIL isn't threadsafe in and of itself. So if you're using these compiled languages as sort of python runners you couldn't multithread python interpreter execution and guarantee the code working. Also as the above comment stated, you could do hacks, but you'd double your memory allocation by needing a python and C/C++/Rust representation for everything that went back and forth.
Same w/ Rust and Python, this is really neat because now each thread could have a GIL without doing exactly what you said. The pyO3 commit to allow subinterpreters was merged 21 days ago, so this might "just work" today: https://github.com/PyO3/pyo3/pull/3446
I drove into a ditch in Costa Rica following google maps. It was the end of any fantasy of ine that they still wanted to organize the world's information. Luckily it only cost $500 or so for the privilege of finding that out for sure.
This was the big turning point for me, and I'm in my forties. Thinking that I couldn't enjoy exercise was mainly because my 'form' was so bad it literally hurt. Luckily you can get better at things, and once you do, or you reach that point where it feels good, then the discipline isn't really needed any more than folks need discipline to play their grueling video games.
The mental health limitations around flight are how you get malaysian air flight 370. Don't say anything, treat anything, work through anything involving mental health because you'll lose your license immediately. Therefore the folks with milder mental illnesses will never solo pilot a plane, and folks with serious psychopathic mental illness, especially if it appears after they begin working, will kill everyone on board.
jarmitage is a legend (in my eyes), so I'm sure he has his own opinions, but TidalCycles (as it is now known) depends on supercollider for both Midi and Sample playback. It communicates to supercollider through the OSC protocol, so it's conceivable supercollider could/can be swapped out for another engine. As is I think the install a bunch of Haskell stuff + install an editor plugin + install supercollider is the largest blocker to getting folks started with tidal. In the pre-tidalcycles era, Tidal played samples (only afaicr) through its own Dirt sample player which was still a separate process, but included with tidal itself. Now it uses SuperDirt which depends on supercollider.
Compared to PD and max/msp, Tidal is far more focused on the pattern language and the magic that can come out of that. Any 'programming as programming' has to be done with Haskell and loaded in as its own functions. Puredata and max/msp both are full (graphical) programming environments with their own quirks and special tricks, but in a way a bit more like Supercollider in that they can speak midi and do playback inside their own engines (afaik).