Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

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

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.

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.

This is how I understood it as well.

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.

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.

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).

> 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.

> 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.

> 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).

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.

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.

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)”

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)"

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

Reply on news.ycombinator.com