From nobody Sun Jan 21 16:04:52 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 4THyqR159Kz57jbp for ; Sun, 21 Jan 2024 16:05:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4THyqQ185gz4r8B for ; Sun, 21 Jan 2024 16:05:06 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-68687ff4038so4671126d6.1 for ; Sun, 21 Jan 2024 08:05:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705853104; x=1706457904; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fUfqP7dMApsCeA3qTDKijtdAEmkpGdCi6ObYd7KYHrk=; b=O4aoCxWOYrBz+Zk+YfUZAY0Icn7LvLR7Gr9HOvQfHO7DrbIO2XBbRL5wnWKSF7BCwn wg2y6bZGNKHcXw5LhDBQiUXxXYd6hi7a3e1mpEJwwsE8uxjkrbw4a0sffOz/2nlYZ/uO 6xYIg8/B9C+9cR/BHVBNu4kIbRbVAV3Xdm+z5gDRyUNB/eGX+JRKxaNIdUL8/GFQmonb bmR/z6boIizLgDtxVKLkG+YhNldnwlusNPe1gI6T73eaosPebOYEq85sIbwG4tShiAB8 VWG/c+bBK6m+bZeRJED5c4SjsC4294QCeeXIwQlQPALDwScqVgIJ7nR6/fQgg9vXvaNV xaOA== X-Gm-Message-State: AOJu0YyZBnuJrfkFRwX7Yyt/fxejO+YyJ508CXvJbQREzp4UpwDIgj34 GqLRmuie6U864RMHWvwjUTCJJJEgSQCwdXSuKwxcxWfWl6dPcwFixW+pgw5LhqtgDQFoIJtvHLC kJBVrGcUs+eInxLImBP0QyWCr7UlKVemi6lM= X-Google-Smtp-Source: AGHT+IFs7CTk4qqHh9jDh3fF37CMxPzBy7zIBVYEkJ8L+u7uOvV0t6Ruv1j+vR1fvMnGWYNnOY+40yOvNCPCDm39lPg= X-Received: by 2002:a0c:aad0:0:b0:685:5e54:2cb5 with SMTP id g16-20020a0caad0000000b006855e542cb5mr3120731qvb.66.1705853104574; Sun, 21 Jan 2024 08:05:04 -0800 (PST) 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 References: <1673801705774097@mail.yandex.ru> <202401210751.40L7pWEF011188@critter.freebsd.dk> <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> In-Reply-To: <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> From: Alan Somers Date: Sun, 21 Jan 2024 09:04:52 -0700 Message-ID: Subject: Re: The Case for Rust (in the base system) To: George Mitchell Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEFALL_USER(0.00)[asomers]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[freebsd]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.51:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.51:from] X-Rspamd-Queue-Id: 4THyqQ185gz4r8B 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. * Why Rust instead of Perl, Java, C#, or Go? The crucial difference between Rust and those other four, basically between Rust and everything else since C++ [1], is that Rust is suitable for low-level systems programming. It lacks memory manangement, green threads, etc. The runtime is small (and optionally can be removed entirely). Rust isn't quite as low-level as C, but it's in about the same position as C++. * Why not just use C++ then? Speaking from experience, I'm far more productive in Rust than C++, and my code has many fewer bugs, too. I had been using C++ professionally for 11 years before I learned about Rust, but after 6 months my Rust skills were better than my C++ skills. That's why I finally realized that I wasn't the cause of my C++ problems; C++ was. In general, it feels like C++ has a cumbersome mix of low-level and high-level features. Smart pointers, for example, are handy. But because it retains so much C-compatibility C++ can't enforce the use of smart pointers. And it can't even warn against the use of dumb pointers. It certainly can't check their lifetimes. But in Rust, all pointers are smart [2], so the compiler can help you avoid a wide range of common bugs. * Rust will go out of fashion by the 2040s Perhaps it will. But Like David Chisnall, I'm afraid that if FreeBSD never modernizes, then it itself will go out of fashion by the 2040s. * " can't be implemented unless written in rust" I don't think anybody has claimed this yet. But I _have_ made a similar claim, that some things can't be written in C. I'll elaborate on the project that started this thread: the fusefs test suite. When I designed the fusefs test suite, I based it around the priniciple of Mocking. Each test case has a client thread that does normal file system access, and a server thread that implements a fuse file server. But it isn't a full implementation of a fuse file server; it's just a shim around a mock object. For each test case, the file server's behavior is programmed with expectations. The mocking technique is so limited and awkward to use in C that almost nobody bothers. Just compare the documentation for CMockery (C) with Mockall (Rust). C++'s Googlemock is somewhere in between. * async Rust sucks I disagree, but that's probably worth a separate email thread of its own. In particular, some of the content on the linked rant is not accurate. * Reimplement CVSUp in Rust That sounds like a challenge! I'm not saying that I want to do it, but I'm still interested to look at how CVSUp was done. But where is it? The port is deleted and the web page is gone. * Rust in base would double our compile times Yes, it would. That's the worst thing about it. * Rust in base would cause massive code bloat. Yes, it would, because in addition to the toolchain and standard library most Rust applications would pull in various dependencies. Command line argument parsing, serialization/deserialization, fancy data structures, etc. For both this and the above reason, I'm really liking imp's proposal for a "make extraworld" - stuff that's in base but depends on an external toolchain. [1] Yes I know about Modula-3, D, etc. But for various reasons those never gained traction. [2] Dumb pointers exist too, but they're almost never used except when binding to a C library. [3] https://github.com/lpabon/cmockery2/blob/master/doc/usage.md [4] https://docs.rs/mockall/latest/mockall/