4 ms·

It’s not being rewritten in Rust. They want to use rust instead of C for extension modules.

oconnor663 9y ago
Could we get a mod edit on the title here? The article itself is called "Using Rust in Mercurial".
jxcl 9y ago
One of us misread the article. I understood it to say that they want to rewrite the core of the Python code to Rust so that they don't have to wait for the Python interpreter to start every time someone uses the hg command. The Rust binary will be able to call Python code, which is basically a complete reversal of what they have now.
- JDevlieghere 9y ago
  This is how I understood it as well.
- oconnor663 9y ago
  I read it as they want it to be possible for some commands to be written in pure rust, but that they expect to maintain the majority of their current Python code.
  - seba_dos1 9y ago
    If it's already possible to write C extensions, then it's already possible to write Rust extensions, so that would be a non-news.
    - oconnor663 9y ago
      I think the idea is that in order to avoid Python interpreter startup time on commands that are primarily written in Rust, they also want to have the main function written in Rust, with Python interpreter startup being an optional codepath (that a majority of the codebase still depends on).
- the_mitsuhiko 9y ago
  > One of us misread the article. I understood it to say that they want to rewrite the core of the Python code to Rust so that they don't have to wait for the Python interpreter to start every time someone uses the hg command. It would still use the Python interpreter internally but they want to skip it for some functionality like the basic command line interface. So they would embed the Python interpreter in their new distribution. However the Python code still just calls out to other Rust code.
  - merb 9y ago
    > However the Python code still just calls out to other Rust code. this will probably be hard. calling back and forth is always harder than into a single direction.
ahupp 9y ago
From the page: "Desired End State: hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today)"
m12k 9y ago
> Desired End State: hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today) I'd say it seems like they want to also flip the ratio of the core around, so it's Rust for the central parts and Python only as needed (whereas today it's Python for the core and C for certain performance critical things).
- wtetzner 9y ago
  I'm not sure they want to flip the ratio as much as the architecture. The entry point would be Rust, but the majority of the code would still be Python.
  - neandrake 9y ago
    I quoted this elsewhere but this part makes it sound like they are intending to move over large parts of the implementation into rust in the long run, migrating away from python due to the size of the project becoming more difficult to maintain > In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.
sctb 9y ago
We've updated the submission title, which was “Mercurial (hg and C extensions) being rewritten in Rust” to that of the article. It's surprisingly easy to mislead, which is one of the reasons we ask submitters to use the original title and not to editorialize.
- deleted 9y ago
  [deleted]
dragonwriter 9y ago
No, they want to flip the relationship of Python and native code; instead of hg being Python with C extensions, they want it to be Rust with an embedded Python interpreter. It's not a total rewrite in Rust, but it's also a more significant change than just replacing C extensions with Rust extensions while maintaining a Python core. Quoting the source material on the “Desired End State”: “hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today)”
deleted 9y ago
[deleted]

Could we get a mod edit on the title here? The article itself is called "Using Rust in Mercurial".

jxcl 9y ago

One of us misread the article. I understood it to say that they want to rewrite the core of the Python code to Rust so that they don't have to wait for the Python interpreter to start every time someone uses the hg command. The Rust binary will be able to call Python code, which is basically a complete reversal of what they have now.

JDevlieghere 9y ago
This is how I understood it as well.
oconnor663 9y ago
I read it as they want it to be possible for some commands to be written in pure rust, but that they expect to maintain the majority of their current Python code.
- seba_dos1 9y ago
  If it's already possible to write C extensions, then it's already possible to write Rust extensions, so that would be a non-news.
  - oconnor663 9y ago
    I think the idea is that in order to avoid Python interpreter startup time on commands that are primarily written in Rust, they also want to have the main function written in Rust, with Python interpreter startup being an optional codepath (that a majority of the codebase still depends on).
the_mitsuhiko 9y ago
> One of us misread the article. I understood it to say that they want to rewrite the core of the Python code to Rust so that they don't have to wait for the Python interpreter to start every time someone uses the hg command. It would still use the Python interpreter internally but they want to skip it for some functionality like the basic command line interface. So they would embed the Python interpreter in their new distribution. However the Python code still just calls out to other Rust code.
- merb 9y ago
  > However the Python code still just calls out to other Rust code. this will probably be hard. calling back and forth is always harder than into a single direction.

ahupp 9y ago

From the page: "Desired End State: hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today)"

m12k 9y ago

> Desired End State: hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today) I'd say it seems like they want to also flip the ratio of the core around, so it's Rust for the central parts and Python only as needed (whereas today it's Python for the core and C for certain performance critical things).

wtetzner 9y ago
I'm not sure they want to flip the ratio as much as the architecture. The entry point would be Rust, but the majority of the code would still be Python.
- neandrake 9y ago
  I quoted this elsewhere but this part makes it sound like they are intending to move over large parts of the implementation into rust in the long run, migrating away from python due to the size of the project becoming more difficult to maintain > In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.

sctb 9y ago

We've updated the submission title, which was “Mercurial (hg and C extensions) being rewritten in Rust” to that of the article. It's surprisingly easy to mislead, which is one of the reasons we ask submitters to use the original title and not to editorialize.

deleted 9y ago
[deleted]

dragonwriter 9y ago

No, they want to flip the relationship of Python and native code; instead of hg being Python with C extensions, they want it to be Rust with an embedded Python interpreter. It's not a total rewrite in Rust, but it's also a more significant change than just replacing C extensions with Rust extensions while maintaining a Python core. Quoting the source material on the “Desired End State”: “hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today)”

deleted 9y ago

[deleted]