From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Consideration for Rust contributions in Emacs Date: Sun, 22 Jan 2023 15:44:19 +0800 Message-ID: <871qnn6mjw.fsf@yahoo.com> References: Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29825"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Troy Hinckley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 22 08:45:39 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJV2o-0007ZM-TW for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Jan 2023 08:45:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJV1v-0002HJ-PQ; Sun, 22 Jan 2023 02:44:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJV1q-0002FY-NC for emacs-devel@gnu.org; Sun, 22 Jan 2023 02:44:38 -0500 Original-Received: from sonic308-56.consmr.mail.ne1.yahoo.com ([66.163.187.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pJV1o-0000iH-5f for emacs-devel@gnu.org; Sun, 22 Jan 2023 02:44:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674373470; bh=2p0Kky0EfaY1WcRq9ypVw6+t6yA9jmmWEvmnOV8YYQQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=TJYGiVpAzlDOIToR/cyZCG4/UUh8pTWeGEhsLWAeTvLA7QSq6iN8JexLbD36mgxoyEyuOC9ZEbzccb5q1JFdGXfHhMfvy63AlSRZqbgBKwrqEiF3R1LqvzIHa44UXHPdB3EKIBWYe+C+0nxgB9Lp9wZ5iZ91Hz1RyZRoq5yZpD/QniF/LqCSXfBBJMT4kpyMfTtsMnEhbK0ozwLpBhs3XF4veqYxKPRpxXhsSTGQYopmw+Fa9rzHpNoCHbR4+0H4WRijp7w4V+1sRP1F7TG+obLtOVz0S4Rd0peTR/jXZD3JzssOULCqGPodF4mduGPGk597OY8VkKa30vXAOtok/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674373470; bh=xS5FGwr6C65jMk/HVsJC1N9bEMXKJbVhFM5QIWtHwyl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=bXlut7QocHCJ0JOyEONNV9Qvkz6l7oxYB0jGZRjVAhbhZyO+3fi8S2y1mkJwN54He5suyI7Kf+e97hhkByanpMm3eVHZmiCgrbcs23hZRVu2TT+2h79PkXrswcX94XzhP4e+Joq0oeiBy4s8VDjfYE7ofOwjqo3oNd/xHM+6o+gV6eataQAa5BoN5cDOsy+3t6vUYOu7RuLOcjLBddRHAUPj3rYDoFxJJxPi8yHUD05Q6KiAVX5okBYsS1jqrjN9WzCgZM+Sm/tBP+CBKqUzQeDTRBPajodcXM3FNvM9XtvsKt3LdYx/UGftaLQ9b7/2m+JqVjwIhreAkkWwLUTvYw== X-YMail-OSG: mIt1hjgVM1lQA2U3ReGaN1QPHjdP8_770NWkKdzqIbithxTvgeSJEc1MOjsjNTH q5RGx9TheZnhOQ_XukUOmHyS7ZlqldYm5iasi1r5uKuRCGpPNurtB8NfsorgRTa0YrnzadoLNAEj xq4bO6yKKlW0aY5ZUctAFoekEtSWURRimNQQLCNgrV3gVtcQgzGyEee8YbYrM1zJTjjZ6n4FJKXz Xxq2ai715vJ79zwkCfsPDlHQLRk0uGwvaC7PMFn0Ck_suCo.cYlsDqa2zecf0mmiCEuSmZRIIJXI GqmOty2MBmi_l45IneBa57O7nWRsQ0sL6GoCxQXpzyWppkkQSJsZoOnTko68tkcC0Lm8rMyL3kOX Hxc0m9sDG4KIQfRy7b.3n6m21bxNN5Acg4YGg__X2c07uDlCaDwuDNaUdUoXpUTsYGZdOqU_JCrT WOU8kfkUX8ufcC3rOOck_0YwY5wN3.Q2J.DFrlFxwLN1LpbDs_A0cnbTPWPMXl4KtABPLtriVK_Y jJUUsuqm2GL40CmYzvhwDHT2iCJ0QbK0.s2fOUPvRkypQyf36FT.P2ulzaSwLUTLlQ2IQapQktOQ dAwGf6cEIMclCypKu_kQghlwPP7vGlwhfxPtv4bkBfyPKxJe4_XxIc25VFmbOKFa2TmSDmNa.glE sNmx4zuxGBiEJuGWflQGbPLztzKHajRrzYtJv5dUuyuPXyKXol7jK928_lRyQ.TI0HNMxKGgIeGq TsOhqN6t13SEy.nevcCKLEesEVFUE3qkl8W0ql2rZYHrzw3JrWN.xFQS1j56SqNElgpjfpZJ8_51 vd5_YMSkUQQLDzW24y59vcv8p8HJg0DXFXx7eX9ge9 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Sun, 22 Jan 2023 07:44:30 +0000 Original-Received: by hermes--production-sg3-84766d64d7-cshk9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d5cef9bd0ccd68e833d6d2c791138dae; Sun, 22 Jan 2023 07:44:25 +0000 (UTC) In-Reply-To: (Troy Hinckley's message of "Sat, 21 Jan 2023 15:48:28 -0700") X-Mailer: WebService/1.1.21096 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.187.31; envelope-from=luangruo@yahoo.com; helo=sonic308-56.consmr.mail.ne1.yahoo.com X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302598 Archived-At: Troy Hinckley writes: > Let assume for the sake of this discussion that there was a some Rust > code that someone wanted to contribute and the maintainers wanted the > functionality it provided. What would be the consideration/objections? It is hard to say for certain, because you have not said what code you have in mind. > 1 The Rust tool-chain is Apache licensed and so is LLVM. There is work > on a GCC backend, but it is not production ready yet. Would Emacs > allow the current Rust tool-chain? No. Emacs code for a platform where GCC is available must be written so that it can be compiled with GCC. We already have this policy in place, and it prevents us from using Objective-C features that are only supported by Clang in the Nextstep. > 2 LLVM (and hence Rust) support fewer targets than GCC. Are there > certain target that LLVM doesn=E2=80=99t support that are important to Em= acs? For example: MS-DOS, via DJGPP. Or, Windows 9X. I use Emacs to code-convert files on a Windows 98 machine used to run government software. And also the various Unix systems that currently do not support LLVM: HP/UX, and AIX. > 3 Many Rust libraries (crates) are MIT and/or Apache licensed. Do all > Libraries used by GNU Emacs need to be GPL or is it sufficient to have > a GPL compatible license? I would be more concerned about how Rust libraries are distributed. Isn't the Rust package manager one of those which download libraries directly from a source code repository? > 4 How sizable of a contribution would be needed for the maintainers to > accept Rust in Emacs core? Would auxiliary functionality be considered > (such as Rust in the Linux Kernel) or would it need to have major > impact. It will probably not be accepted. > 5 Concerns over having more than one core language in GNU Emacs. Yes. > 6 Concerns over using such a new language. Rust still changes at a > fast pace relative to C and it=E2=80=99s future is less certain then a mo= re > established language. Yes. Rust is not widely available at all, while C is available for every platform, from 8 bit microcontrollers, to 16 and 24-bit digital signal processors, and 32-bit and 64-bit consumer computers, and will remain that way for the foreseeable future. Emacs is a portable program written in C. Thus, any code that is not strictly a port to some other platform should also be written in standard C99. In the past, people wanted to rewrite Emacs in Scheme. Then, it was C++. Then, it was Java. Now, it is Rust. Part of the reason Emacs has existed for so long is that it has not given in to those demands, and remains a highly portable program, written in a standardized language, that has remained more or less constant since it Emacs was written. Rust, on the other hand, frequently releases breaking changes with new versions of the programming language, and is not standardized in any way. This shows in that even an operating system supposedly written in Rust provides a C toolchain and C runtime library. Now, judging by recent internet chatter, you probably think Rust will magically allow Emacs Lisp to run on different threads. Some people seem to have this idea that because the Rust compiler will try to prevent two threads from having access to a variable at the same time, writing Emacs in Rust will, as if by magic, allow multiple Lisp threads to run at once. That is not true. The Rust compiler does not try to avoid concurrency pitfalls aside from the simple data race: for example, locking a non-recursive mutex twice is not only a programming error, it is undefined behavior! In addition, locking (and not locking) needs to be carefully thought out, or it will slow down single threaded execution. For example, a common pattern found inside Emacs code is: for (; CONSP (tem); tem =3D XCDR (tem)) /* Do something with XCAR (tem) */; XCAR and XCDR work fine unchanged on most machines without needing any kind of locking, as Lisp_Cons is always aligned to Lisp_Object. However, it does not work on two machines, which either need explicit memory barrier instructions (or in the case of vectors, mutexes): On the (64-bit) Alpha, memory ordering across CPUs is extremely lax, and without the appropriate barrier instructions, even aligned reads and writes of 64 bit words are not atomic. On x86 (and possibly other platforms) with --with-wide-int, reads and writes of Lisp_Object require separate moves and stores to and from two 32 bit registers, which is obviously not atomic. Then, if XCDR (tem) reads from a cons whose cdr cell is in the process of being written to, then it may dereference a nonsense pointer. And contrasting that, this code is perfectly safe in C, on x86. The assert will never trigger: static unsigned int foo; thread_1 () { foo++; } thread_2 () { assert (foo <=3D 1); } main () { /* start thread_1 and thread_2 at the same time. */ } I believe the Rust compiler will force you to add some code in that case. Imagine how much overhead it would add if Emacs had to lock a Lisp_Cons before reading or writing to it. But the Lisp interpreter is the easy part, especially since we already have much of the necessary interpreter state moved off into struct thread_state. A lot of other code which is algorithmically non reentrant will have to be made reentrant, and papering mutexes and atomics over them to satisfy compile-time checks will not do that. For example, how do you propose to rewrite process.c to allow two threads to enter wait_reading_process_output at the same time? Who gets SIGCHLD? Who gets to read process output? In which thread do process filters run? In the end, you will have to do the same work you would need to in C, with the added trouble of adding code in a new language, making everyone else learn the new language, while throwing portability down the drain. That doesn't sound like a good tradeoff to me.