181–190 of 513 posts
Earlier quoted context omitted.
> I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge. And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell. But Java was still better at it than C or C++ at the time.
In your opinion. Some of us believe the exact opposite.
Earlier quoted context omitted.
How do you suggest we could teach proper threading (what is that?) to the masses?
Rust is a brilliant lesson in using traditional threading safely. It uses & for thread-shared types and constrains &mut to a single thread, which naturally causes people to keep single-threaded data on an object only accessible from a single thread, and make multithreaded data either immutable, mutex-protected, or atomic. Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are an…
Earlier quoted context omitted.
In GIL Python, you might think you could speed something up by multithreading, but it turns out you can't. The GIL will just run it serially anyways. No-GIL means it is possible to run things in parallel (without resorting to fancy C extensions).
In theory it's easy. In practice you need to design programs very carefully to leverage multiple threads. The same is true for multiple processes, yet that is much easier to reason about and a lot more likely to get it right.
I get that it's a hard problem, but it isn't a guessing game. Concurrency has always required one to carefully design their program. We will see how Python implements these new APIs, but I trust it will be approachable to those who want to do it.
Earlier quoted context omitted.
Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the proposal and work is to make non-GIL mode entirely optional and not the default. It just means for the brave few that flip it on and use it, be prepared to spend a huge amount of time finding and fixing subtle race conditions in decades of old python library code. T…
Does Python have a lot of secondary dependencies? I could see someone pulling in two dependencies, not realize they both use the same unsafe library, and end up having them step all over each other.
Earlier quoted context omitted.
Rust is a brilliant lesson in using traditional threading safely. It uses & for thread-shared types and constrains &mut to a single thread, which naturally causes people to keep single-threaded data on an object only accessible from a single thread, and make multithreaded data either immutable, mutex-protected, or atomic. Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are an…
I don't quite see how Rust approach to multithreading is that amazing. Rust does nothing to magically prevent race conditions for you. Rust safety does not encompass race conditions, starvation, etc. What it does is defensively prevent you from sharing mutable variables without explicitly opting for it. It's good for catching careless sharing issues, but not much more.
I also struggle to understand the threading model of COM and C libraries like libusb (https://libusb.sourceforge.io/api-1.0/libusb_mtasync.html), though that might just be me, and each library tends to have a different threading model. Rust's Send/Sync is a 90% solution which you can learn upfront, is checked by the compiler, and applies to all libraries and works for most use cases.
Earlier quoted context omitted.
The intent is to make no GIL the default eventually.
I don't think this is true. There are fairly strong voices on both sides inside the community, at this time it's pretty uncertain. To quote Guido: >Let’s not blow it this time. If we’re going forward with nogil (and I’m not saying we are, but I can’t exclude it), let’s make sure there is a way to be able to import extensions requiring the GIL in a nogil interpreter without any additional shenanigans https://discuss.p…
> Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility). We don’t want to wait too long with this, because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.
https://discuss.python.org/t/a-steering-council-notice-about...
Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…
No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these. No one's flipping a switch and breaking mountains of sketchy C.
Ugh, Nomenclature is hard
Because non-GIL compatible doesn't mean GIL incompatible
Earlier quoted context omitted.
Without the last sentence, your comment would be better.
It's not nice but it is true. "Dur dur this is just like 2 -> 3." HN had always been susceptible to drive-by ignorant comments, but it's reaching new levels. There's literally nothing of substance to the suggestion. (And if you think there is, present an actual informed argument.)
Earlier quoted context omitted.
As sibling comments says, GIL mode can run no-GIL code. Entirely different from 2->3. That analogy is so poorly applicable it's laughable.
Without the last sentence, your comment would be better.