Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can't speak for the OP but here's what I think they may have meant and my intuitions agree with them as well.

In python I mostly use threads for non-CPU intensive tasks like IO or timers or event handling and I rarely implement these myself.

However for CPU intensive tasks, there's rarely any point to having 10 threads in Python because they all have to run on one core because of the GIL. Therefore when working with python the GIL indirectly lets me never have to think about writing concurrent CPU intensive code AND I know others wouldn't do it too because it wouldn't make sense most of the time. This is leads to a significant reduction in cognitive load when thinking about solving a problem in Python. And it isn't about thread-safety but that in concurrent code I have to worry how other threads might change the values of shared variables and global variables of which there are many.

Instead the GIL lets me think synchronously, write synchronous code and when I needed to parallelize my work I use multiprocessing where my synchronous code and assumptions work perfectly because each process has its own GIL and I explicitly pass shared variables to each of the processes.

I don't know enough to comment on the good or the bad of GIL. Just my two cents about how I think about code with Python in it's current state.



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: