unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Rust freedom issue claim
Date: Wed, 26 May 2021 17:14:15 +0200	[thread overview]
Message-ID: <20210526151415.yer3zduopggr6ds6@thebird.nl> (raw)
In-Reply-To: <87k0nlsh0c.fsf@gnu.org>

On Wed, May 26, 2021 at 04:32:03PM +0200, Ludovic Courtès wrote:
> That’s a somewhat different topic.  FWIW, I’m both excited at the idea
> of having a memory-safe replacement for C gaining momentum, and
> frightened by the prospects of Rust being this replacement, for many
> reasons including: Rust does not have a good bootstrapping story, as we
> know all too well, Cargo encourages sloppy package distribution à la
> npm, Rust in the kernel would give a false sense of safety (it’s still
> that big monolithic blob!), and the Rust community is very much
> anti-copyleft.

Having adopted Rust for some of our bioinformatics work, I can fully
agree. It is actually hard to use Rust without Cargo and it is an
implosion npm-style waiting to happen if the most trivial program
already imports 100+ external packages - some of doubtful quality.

Another thing I have against Rust is its syntax - but that is
(arguably) taste. I can't believe references are written with an
ampersand - and they are so common it is in your face all the time.
That is just noise. And sometimes the borrow checker really gets in
the way (and I pine for GC). We are sticking with Rust though because
the compiler works hard and is a sucker for detail, so it helps both
less and more experienced programmers to avoid C/C++ traps. Also Rust
has no OOP that people can use - I am very happy about that. In short
it is a fairly pragmatic FP language with some nice compile time
features. I don't love it but it is an OK compromise.

For kernels I completely agree with you. Memory safety is a red
herring because we face much deeper problems. Open hardware and
message passing is the way forward.

Oh, did you know Rust expands all sources into one 'blob' for
compilation? At the crate level. It led to the meme: "The Rust
programming language compiles fast software slowly."

I have not hit real issues yet with compilation speed, but it feels
like we regressed to huge C++ template expansion...

> Guix, related projects such as Mes, Gash, and the Shepherd, together
> with the Hurd, offer a very different and (to me) more appealing vision
> for a user-empowering, safer, more robust, and yet POSIX-compliant OS.

Good architecture is far more important than a borrow checker.

Pj.


  reply	other threads:[~2021-05-26 15:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  3:24 Rust freedom issue claim Bone Baboon
2021-05-25  2:01 ` Bone Baboon
2021-05-26 14:32 ` Ludovic Courtès
2021-05-26 15:14   ` Pjotr Prins [this message]
2021-05-27 14:47     ` Joshua Branson
2021-05-27 16:28       ` Pjotr Prins
2021-05-27 20:23       ` Jack Hill
2021-06-03 18:38   ` Bone Baboon
2021-06-08 13:00     ` Ludovic Courtès
2021-06-12 18:49       ` Bone Baboon
2021-06-12 21:31         ` Vagrant Cascadian
2021-06-13 18:20         ` Leo Famulari
2021-06-15 12:38           ` Bone Baboon
2021-06-19  3:21       ` Bone Baboon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210526151415.yer3zduopggr6ds6@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).