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.
I agree, but so is the start up cost of so many other tools people use such as emacs/vim, dvorak/colemak, chorded keyboards, etc.
That being said, I think the biggest limiter is the fact that you can only really use this if you work from home alone, can't imagine using this anywhere outside or at the office.
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
