From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Troy Hinckley Newsgroups: gmane.emacs.devel Subject: Re: Consideration for Rust contributions in Emacs Date: Sun, 22 Jan 2023 20:37:09 -0700 Message-ID: <66c86c61-93ac-4723-81a4-ced034f61550@Spark> References: <878rhuc79x.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="63ce0106_109cf92e_5015" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="836"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Sean Allred Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 23 12:55:12 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 1pJvPr-000Abz-Lh for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Jan 2023 12:55:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJvPI-0006nD-L9; Mon, 23 Jan 2023 06:54:36 -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 1pJneb-0007MW-UZ for emacs-devel@gnu.org; Sun, 22 Jan 2023 22:37:53 -0500 Original-Received: from sender4-op-o12.zoho.com ([136.143.188.12]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJneZ-0000XI-QG for emacs-devel@gnu.org; Sun, 22 Jan 2023 22:37:53 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1674445069; cv=none; d=zohomail.com; s=zohoarc; b=im2mGZQQPkNxb/nDHCGb3BOTQ5ASt079vjSC6+Qg+tCXes6ENXJf28XvsijiZOLm6WzGsdG/c4ez0QEAm12QnTPF9bjrrjL4UDBfg9cVcZlQtfVU/vPUloQNNCtC6HpWPMzxdkZ13hsmW5OSUpqLJzumaYjWxE9z7vrx4CVaFJU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1674445069; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=6LHXyUmE2+Qqji60Cim/QkbregJjSLWFh1fASWr3PTE=; b=J48lBIO8UMvVQVU0kiTLuExOqVPqsnGsmdrl/uMSnZbGEhQ0bg1WAM65L6yUz2eVHANphT8ihDiooOw4rErK9gdr38QBO0zWC6Wva/B5/26gDx5qfbrXEpRQdK5j2YHdJ8c8AlMeoiyGMr0HiE6sVC9wHj3tk46oqIbNIr7p474= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=dabrev.com; spf=pass smtp.mailfrom=comms@dabrev.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1674445069; s=zoho; d=dabrev.com; i=comms@dabrev.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Message-Id:Reply-To; bh=6LHXyUmE2+Qqji60Cim/QkbregJjSLWFh1fASWr3PTE=; b=k87LGxhviTUzIvkQNz82Y1uAx0tQqQiffyXwMR3FUV4DYkgV1u59emg/UQWJvwAy blWeXPL9y9Yn7hNdm2xm0khYxOBj5GJsyXR897KO+WtBIZWXfbnJxqgMovPXwxRnYEt VjtSekmSTIhFZvRR5lR6Gzu84vpeJytp9pAMnENU= Original-Received: from [192.168.1.139] (h24-54-181-16.ftcmco.broadband.dynamic.tds.net [24.54.181.16]) by mx.zohomail.com with SMTPS id 1674445067853729.4955275672867; Sun, 22 Jan 2023 19:37:47 -0800 (PST) In-Reply-To: <878rhuc79x.fsf@gmail.com> X-Readdle-Message-ID: 66c86c61-93ac-4723-81a4-ced034f61550@Spark X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.12; envelope-from=comms@dabrev.com; helo=sender4-op-o12.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 23 Jan 2023 06:54:35 -0500 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:302609 Archived-At: --63ce0106_109cf92e_5015 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks Sean=21 I should have been clearer in my question that I don=E2=80=99t have any R= ust code that I want to contribute to GNU Emacs, and I don=E2=80=99t know= anyone who does. This is a hypothetical. I don=E2=80=99t think Rust should be added to the Emacs core. The core is= well tested and battle hardened C and Rust would not add much value. I guess a clearer question would be: are there any fundamental/ideologica= l reasons Rust could not be part of GNU Emacs=3F Ignoring technical trade= offs and complexity etc. Po Lu already provided one; Emacs needs to support old platforms like MS-= DOS. So that rules out LLVM. Are there others=3F I am particularly interested in issues surrounding li= censing, such as the question I posed above about libraries. On Jan 22, 2023 at 7:30 PM -0700, Sean Allred , = wrote: > Hi Troy=21 > > Thanks for raising the topic. I think this is my first time posting on > the list, but this is a topic that means quite a bit to me (and is > something I've had some experience with in other projects). > > Using Rust in Emacs is an exciting prospect that draws on the general > buzz that Rust has been generating. I personally enjoy using Rust for > personal and professional projects alike. As you've noticed, though, it= s > use in Emacs is not without its concerns. > > Troy Hinckley writes: > > I've had a discussion with several people recently about future > > possibilities of Rust in GNU Emacs core. I could not find an answer t= o > > this on the archives, so if it has been resolved previously please > > point me to that thread. > > > > 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= =3F > > I would add to your list of considerations that Rust is designed for an= > almost singular purpose that it performs very well: memory-safety. I > don't pay *that* much attention to this list, but I also haven't seen > many bug reports concerning memory mismanagement -- and I certainly > haven't experienced any such bugs myself. I suspect this is due to the > relatively small C core that provides a memory-safe runtime for the > elisp that comprises the rest of emacs. Assuming memory-safety isn't a > demonstrated problem that emacs development struggles with, > incorporating Rust into its dev pipeline is going to be a very hard > sell: > > Does Rust actually solve a problem emacs has=3F > > I don't know that the answer is 'no'. =46rankly, I don't think I'm > qualified to offer an opinion here. More importantly to your goals, I > don't see where you've shown why you believe the answer is 'yes'. > > In general (and this certainly doesn't apply to just emacs), to > introduce a new technology into a stable system, you'll need to be able= > to demonstrate concrete gains that *measurably* outweigh the costs. > Introducing a new technology will inherently destablize any affected > components of the system -- this is very difficult to justify in any > large project. =46eel-good syntax isn't usually a compelling reason -- > especially in a project that's developed a lisp runtime where syntax is= > already cheap to develop. > > The last significant endeavor in this direction that I'm aware of was > Remacs -- but it appears development has petered out for one reason or > another. I don't think it's a lost cause in the grand scheme of things,= > but this clearly is not a ship that can/would/should change course very= > easily. > > -- > > If it is something you are comfortable using and they meet your goals, > I'd like to point out the recent support for dynamic modules. Rust has > pretty solid =46=46I support in my experience. If needed, you may(=3F) = have > better luck submitting patches to hook into / advise core functions in > lisp -- and then using those hooks in a dynamic module implemented in > the language of your choice. > > -Sean > > -- > Sean Allred --63ce0106_109cf92e_5015 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks Sean=21&=23160;

I should have been clearer in my question that I don=E2=80=99t have any R= ust code that I want to contribute to GNU Emacs, and I don=E2=80=99t know= anyone who does. This is a hypothetical.&=23160;

I don=E2=80=99t think Rust should be added to the Emacs core. The core is= well tested and battle hardened C and Rust would not add much value.&=23= 160;

I guess a clearer question would be: are there any fundamental/ideologica= l reasons Rust could not be part of GNU Emacs=3F Ignoring technical trade= offs and complexity etc.

Po Lu already provided one; Emacs needs to support old platforms like MS-= DOS. So that rules out LLVM.&=23160;

Are there others=3F I am particularly interested in issues surrounding li= censing, such as the question I posed above about libraries.&=23160;&=231= 60;

On Jan 22, 2023 at 7:30 PM -0700, S= ean Allred <allred.sean=40gmail.com>, wrote:
Hi Troy=21

Thanks for raising the topic. I think this is my first time posting on the list, but this is a topic that means quite a bit to me (and is
something I've had some experience with in other projects).

Using Rust in Emacs is an exciting prospect that draws on the general
buzz that Rust has been generating. I personally enjoy using Rust for
personal and professional projects alike. As you've noticed, though, its<= br /> use in Emacs is not without its concerns.

Troy Hinckley <comms=40dabrev.com> writes:
I've had a discussion with several people r= ecently about future
possibilities of Rust in GNU Emacs core. I could not find an answer to this on the archives, so if it has been resolved previously please
point me to that thread.

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=3F<= br />

I would add to your list of considerations that Rust is designed for an almost singular purpose that it performs very well: memory-safety. I
don't pay *that* much attention to this list, but I also haven't seen
many bug reports concerning memory mismanagement -- and I certainly
= haven't experienced any such bugs myself. I suspect this is due to the relatively small C core that provides a memory-safe runtime for the
= elisp that comprises the rest of emacs. Assuming memory-safety isn't a demonstrated problem that emacs development struggles with,
incorporating Rust into its dev pipeline is going to be a very hard
= sell:

Does Rust actually solve a problem emacs has=3F

I don't know that the answer is 'no'. =46rankly, I don't think I'm
qualified to offer an opinion here. More importantly to your goals, I
don't see where you've shown why you believe the answer is 'yes'.

In general (and this certainly doesn't apply to just emacs), to
introduce a new technology into a stable system, you'll need to be able to demonstrate concrete gains that *measurably* outweigh the costs.
= Introducing a new technology will inherently destablize any affected
components of the system -- this is very difficult to justify in any
large project. =46eel-good syntax isn't usually a compelling reason -- especially in a project that's developed a lisp runtime where syntax is already cheap to develop.

The last significant endeavor in this direction that I'm aware of was
Remacs -- but it appears development has petered out for one reason or another. I don't think it's a lost cause in the grand scheme of things, but this clearly is not a ship that can/would/should change course very easily.

--

If it is something you are comfortable using and they meet your goals, I'd like to point out the recent support for dynamic modules. Rust has pretty solid =46=46I support in my experience. If needed, you may(=3F) ha= ve
better luck submitting patches to hook into / advise core functions in lisp -- and then using those hooks in a dynamic module implemented in
the language of your choice.

-Sean

--
Sean Allred
--63ce0106_109cf92e_5015--