Showing content from http://mail.python.org/pipermail/python-dev/attachments/20180503/f476cdea/attachment.html below:
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 3 May 2018 at 07:31 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 May 2018 at 15:56, Glenn Linderman <span dir="ltr"><<a href="mailto:v+python@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#330033" bgcolor="#FFFFFF"><span>
<div class="m_5807729826824395402m_-2281398088625153995moz-cite-prefix">On 5/2/2018 8:56 PM, Gregory Szorc
wrote:<br>
</div>
<blockquote type="cite">Nobody
in the project is seriously talking about a complete rewrite in
Rust. Contributors to the project have varying opinions on how
aggressively Rust should be utilized. People who contribute to the
C code, low-level primitives (like storage, deltas, etc), and
those who care about performance tend to want more Rust. One thing
we almost universally agree on is that we want to rewrite all of
Mercurial's C code in Rust. I anticipate that figuring out the
balance between Rust and Python in Mercurial will be an ongoing
conversation/process for the next few years.</blockquote></span>
Have you considered simply rewriting CPython in Rust?<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FWIW, I'd actually like to see Rust approved as a language for writing stdlib extension modules, but actually ever making that change in policy would require a concrete motivating use case.<br></div></div></div></div></blockquote><div><br></div><div>Eric Snow, Barry Warsaw, and I have actually discussed this as part of our weekly open source office hours as work where we tend to talk about massive ideas that would take multiple people full-time to accomplish. :)<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#330033" bgcolor="#FFFFFF">
And yes, the 4th word in that question was intended to produce peals
of shocked laughter. But why Rust? Why not Go?<br></div></blockquote><br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div class="gmail_quote">Trying to get two different garbage collection engines to play nice with each other is a recipe for significant pain, since you can easily end up with uncollectable cycles that neither GC system has complete visibility into (all it needs is a loop from PyObject A -> Go Object B -> back to PyObject A).<br><br></div><div class="gmail_quote">Combining Python and Rust can still get into that kind of trouble when using reference counting on the Rust side, but it's a lot easier to avoid than it is in runtimes with mandatory GC.<br></div></div></div></blockquote><div><br></div><div><a href="https://doc.rust-lang.org/rust-by-example/scope/raii.html">Rust supports RAII</a> so it shouldn't be that bad. <br></div></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4