Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Python interpreter rewritten in Rust, that can run pip

rustpython.github.io

Post reply on HN
Print view View original

21–30 of 53 posts

Re: A Python interpreter rewritten in Rust, that can run pip

#21

Post by Jasper_ »

Phrodo_00 wrote: post #19
glandium wrote: post #17

Earlier quoted context omitted.

I suspect an interpreter that "solves" the GIL problem will break tons of modules that currently only work in concurrent contexts because the GIL exists.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

OK, I'll bite: how?

They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

Re: A Python interpreter rewritten in Rust, that can run pip

#22

Post by tyingq »

Jasper_ wrote: post #21
Phrodo_00 wrote: post #19

Earlier quoted context omitted.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

OK, I'll bite: how? They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

Here's the detail for Jython: https://jython.readthedocs.io/en/latest/Concurrency/

Skip down to "thread safety"

Re: A Python interpreter rewritten in Rust, that can run pip

#23

Post by ris »

Jasper_ wrote: post #21
Phrodo_00 wrote: post #19

Earlier quoted context omitted.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

OK, I'll bite: how? They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

> They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model.

"Ownership models" are not a given. C++ has no "ownership model" and it doesn't lock around objects. Multi-threading users are just given the synchronization primitives and are expected to manage their own solutions.

The same is true in Python: https://docs.python.org/3/library/threading.html#lock-object... - in fact, if you're using objects simultaneously from multiple threads without using some sort of locking scheme, you're probably already in trouble...

The main thing that's keeping the GIL around is the reference-counting garbage collector. If your python implementation uses its own GC mechanism, it doesn't have this problem.

Re: A Python interpreter rewritten in Rust, that can run pip

#24

Post by corytheboyd »

amelius wrote: post #16

Does it include a concurrent garbage collector? And does it solve the infamous GIL (global interpreter lock) problem?

I’m genuinely curious why people want to work around the GIL in languages like Python and Ruby. I very much do not want my simple interpreted language to inherit the complexity of true concurrency. Why not just use a different language?

Re: A Python interpreter rewritten in Rust, that can run pip

#25

Post by afarrell »

corytheboyd wrote: post #24
amelius wrote: post #16

Does it include a concurrent garbage collector? And does it solve the infamous GIL (global interpreter lock) problem?

I’m genuinely curious why people want to work around the GIL in languages like Python and Ruby. I very much do not want my simple interpreted language to inherit the complexity of true concurrency. Why not just use a different language?

If a company has 200+ developers already working on a 10-year-old codebase in the language, then the word "just" has a lot of heavy lifting to do in that question.

Re: A Python interpreter rewritten in Rust, that can run pip

#26

Post by TylerE »

Jasper_ wrote: post #21
Phrodo_00 wrote: post #19

Earlier quoted context omitted.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

OK, I'll bite: how? They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

It's not difficulty. It's been done experimentally - exactly as you say. They use locks around everything.

What's hard is doing it without dumpstering single thread performance.

Re: A Python interpreter rewritten in Rust, that can run pip

#27

Post by duckerude »

corytheboyd wrote: post #24
amelius wrote: post #16

Does it include a concurrent garbage collector? And does it solve the infamous GIL (global interpreter lock) problem?

I’m genuinely curious why people want to work around the GIL in languages like Python and Ruby. I very much do not want my simple interpreted language to inherit the complexity of true concurrency. Why not just use a different language?

The GIL doesn't really let you escape the horrors of concurrency, at least in CPython. Threads can't execute at the same time, but they can interleave in inconvenient ways.

Re: A Python interpreter rewritten in Rust, that can run pip

#29

Post by pansa2 »

corytheboyd wrote: post #24
amelius wrote: post #16

Does it include a concurrent garbage collector? And does it solve the infamous GIL (global interpreter lock) problem?

I’m genuinely curious why people want to work around the GIL in languages like Python and Ruby. I very much do not want my simple interpreted language to inherit the complexity of true concurrency. Why not just use a different language?

> Why not just use a different language?

I’ve asked myself this question (in a different context) and have concluded that, in general, developers are incredibly resistant to learning and using new languages.

For example: if they weren’t, then server-side JavaScript would never have become popular.

Post reply on HN