5
$\begingroup$

There has been a proposal to start implementing some python optional extension modules in Rust. Eventually, the authors hope to make Rust a core dependency of the language.

This creates some interesting paradoxes though. Currently, building Rust requires both an older version of itself, and Python. Based on reading the thread it seems people have some good ideas how to solve these issues though I'm not sure how they would work.

However, a bigger issue is glibc's dependence on python. glibc is essential for being able to communicate to the operating system and definitely needed both for building Python and Rust. That means the 3 projects will now all 3 depend on both the other tools.

How will porting Python or Rust to new architectures be possible in such a world?

$\endgroup$
4
  • 2
    $\begingroup$ By hoping nobody loses the executables :P $\endgroup$ Commented Nov 18 at 17:28
  • 3
    $\begingroup$ It's impossible to create something that can't be bootstrapped. Because the thing exists; in the worst case, just follow the process that was used to make it. Note that even before considering Rust, you say glibc depends on Python, but CPython is implemented in C. So the same sort of issue already existed, and it is still not really an issue for the same reasons. $\endgroup$ Commented Nov 19 at 21:32
  • $\begingroup$ @KarlKnechtel you can't bootstrap an interpreter (barring semi-compiler things like Futamura projections) $\endgroup$ Commented Nov 20 at 13:08
  • 3
    $\begingroup$ @KarlKnechtel It may be impractical to go back to early steps, because they depend on technology that no longer exists. E.g. the first compiler ran on a TRS-80, and the code is on a cassette tape. $\endgroup$ Commented Nov 20 at 16:01

1 Answer 1

Reset to default
8
$\begingroup$

Cross compile all three, as with any other project.

The number of subproject names or your perception of the organization does not change anything in that regard (except maybe complexity of organizing and executing that transition).

I bet that, if you take a closer look, you will find more "languages" already, like bash, make etc.

Edit: "Requires old versions" equally isn't an issue if the new code does not require new features which is ensured by being able to compile it at all. The only important part is to ensure that old versions in the complete cycle can be used to ensure that there isn't a rollout order dependency which would by an issue for practical reasons.

$\endgroup$
3
  • 6
    $\begingroup$ There are about 5 production-ready, industrial-strength, mainstream implementations of Python with another dozen or so in various stages of experimentation, development, or abandonment. I am pretty sure at least one of those implementations can already or could be modified to build CPython and/or rustc. Likewise, rustc can be built without glibc, e.g., on Windows or by using musl. There are currently bugs when doing that, but that's just development work, not a fundamental incompatibility. Generally, I agree: this is just bootstrapping, that multiple languages are in play is a red herring. $\endgroup$ Commented Nov 19 at 8:36
  • 5
    $\begingroup$ rustc itself can also be built with mrustc. (mrustc is not a full compiler, but specifically targeted at building assumed correct versions of rustc) $\endgroup$ Commented Nov 19 at 15:26
  • $\begingroup$ @JörgWMittag Your point is valid. But in this case the multiple languages come from different projects with different governances. For example, there's the (minuscule) risk that any 2 projects might delete mutual dependencies thinking that it's no longer neccessary, and/or that it can be rebuilt with the other. :-) $\endgroup$ Commented Nov 20 at 17:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.