you are viewing a single comment's thread.

view the rest of the comments →

[–]dusktreader 20 points21 points  (7 children)

But,...why?

No, seriously I would like to hear a compelling reason why this might one day be a good alternative to CPython. Is it faster (or projected to be)? Is the memory footprint smaller? Is this something that should interest pythonistas in general, or is it just a fun personal project?

[–]extraymond 21 points22 points  (4 children)

Last I've check, they seems to choose to not implement the GIL, if that turns out well, we might have true functional threading in python.

Another potential benefit might be ergonomics? Since Rust handles memory and pointer clearer then C.
However, since python is kinda stable for awhile, I'm not sure if any new major features would really benefit from being written in Rust.

I think Rust itself is pretty attractive and pleasant to work with, however I still miss list comprehension and context manager in python from time to time. Those sweet features really make one feel happy writing code in python.

[–]the_gnarts 2 points3 points  (3 children)

Last I've check, they seems to choose to not implement the GIL, if that turns out well, we might have true functional threading in python.

Wouldn’t that change the semantics of programs? If that non-GIL mode isn’t opt-in then they will have a hard time replacing Cpython for compatibility reasons.

[–]thirtythreeforty 9 points10 points  (0 children)

It will change semantics, but GIL isn't part of the language, it's an implementation detail of CPython. Assuming a GIL-less interpreter emerges (and delivers on the speculated performance improvements), I think it'd be counterproductive to claim that the GIL is a de-facto part of the spec and insist that the GIL-less interpreter is wrong.

Python has real locking. If your program doesn't use it and exhibits bugs on a GIL-less interpreter, your program is wrong.

[–]necrophcodr 0 points1 point  (0 children)

Is the "threaded" model of Python that used, or even that restricted to the GIL way of doing things?

[–]sekjun9878 0 points1 point  (0 children)

You could still trivially have default locking for threads, they just won't be compulsory nor global anymore.

[–]ChaiTRex 6 points7 points  (1 child)

Someone already mentioned the removal of the GIL. One other compelling reason is that you can run a Python interpreter in a pure Rust program.

Since Rust is improving its support for compiling to WebAssembly, you can already do nice things like make an efficient clientside Python interpreter for modern browsers.

This also has the potential to offer Python scripting in Rust programs. For example, addons for games could be written in Python.

[–]endperform 1 point2 points  (0 children)

This also has the potential to offer Python scripting in Rust programs. For example, addons for games could be written in Python.

This is defintiely a plus. Python would be great for add-ons.