From nobody Sun Jan 21 16:50:38 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4THzr726T8z57ms9 for ; Sun, 21 Jan 2024 16:50:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4THzr65rnpz43VQ; Sun, 21 Jan 2024 16:50:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 40LGocdW084017; Sun, 21 Jan 2024 18:50:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 40LGocdW084017 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 40LGockE084016; Sun, 21 Jan 2024 18:50:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jan 2024 18:50:38 +0200 From: Konstantin Belousov To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: References: <1673801705774097@mail.yandex.ru> <202401210751.40L7pWEF011188@critter.freebsd.dk> <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4THzr65rnpz43VQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sun, Jan 21, 2024 at 09:04:52AM -0700, Alan Somers wrote: > Wow, there have been a lot of responses. I think I touched on a > sensitive issue. I'll group everything together in one reply. TLDR; > I think imp's proposal is best. > > * Rust's ABI is too unstable to use for libraries > > This actually isn't a problem. The stability situation for the Rust ABI is > similar to C++; you can't link a C++ app to a C++ library unless they were both > built with the same compiler version. The C ABI, of course, is quite stable. > And it's very easy to build a Rust library as a cdylib so that C applications > can access it. But there are restrictions: the library's public API can't do > things that C can't, like generic functions. I do not think this paragraph is accurate. First, there is C++ ABI, that is followed by compilers, and divergences are treated as serious bugs. Second, even if you limit Rust library to C-representable features, it is still not guaranteed to have stable external ABI. You need to apply a lot of FFI powder to the interface, starting with repr(C) for types (otherwise layou is not stable) and functions name mangling control (again no guarantee for the mangling scheme stability), ending with proper types use and absence of definition what is C-compatible interface.