The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rich Morin <>
To: The Eunuchs Hysterical Society <>
Subject: Re: [TUHS] more about Brian...
Date: Thu, 3 Feb 2022 21:11:14 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Well, this topic certainly took an odd turn.  Owell...

> On Feb 3, 2022, at 18:23, Adam Thornton <> wrote:
> It feels like the tide has turned from Go to Rust.  ...

The incursions of Rust (and not Go) into Linux, Mozilla, and such may indicate a trend.  

> Although a bit outdated, I stand by what I wrote about Go several (six?) years ago:

I quite enjoyed this and found it to be informative, as well.  My personal reaction to Go (mostly derived from skimming Brian's book) is that (a) it's well tuned to Google's needs and (b) not well tuned to mine.  Specifically...

Google needs a language which runs efficiently and links in a reasonable amount of time, even when HUGE sets of libraries are involved.  It also needs a convenient way to do massive concurrency.  Finally, it needs zillions of programmers to be fungible, dropping into code bases that they've never seen before, without tripping over landmines.  My impression is that Go meets these criteria admirably.  But, horses for courses...

I program mostly on my own, so most of these criteria are irrelevant to my needs.  I use Ruby for short scripts and Elixir for larger programs.  Neither one is blazingly fast, but they both feel comfortable to write in.  I like Matz's taste in design and think that José Valim has pulled together a very appealing mix of concepts and syntax from Clojure, Erlang, F#, Lisp, Ruby, etc.

One problem I have with Go is that it doesn't match the way I code.  Kind of like (I imagine) an oil painter might work, I start with broad swatches and fill in the details over time.  So, any new program is likely to have stubs lying about, waiting to be implemented.  Also, I might well calculate a variable only to support a trace statement which is currently commented out.  Go is very intolerant of this sort of thing: an unused variable, IIRC, is a fatal error.  Google isn't paying me to put up with this sort of thing, so I don't.

Another problem I have with Go is the concurrency model.  First, it uses threads, which I've never felt competent to use safely.  Shared mutable state is one of those things that seem to me like an accident waiting to happen.  Also, though I have no real experience with CSP, it seems like the Actor model may be better suited to exploratory programming.

Getting back to Rust, my impression is that its design assumes that having the computer put up guard rails will (mostly) keep programmers from making catastrophic mistakes.  In contrast, the Erlang (and thus Elixir) approach assumes that things WILL crash and that the important thing is to make sure that the system as a whole keeps running smoothly.  So, for example, it provides supervision trees which can handle any crash of an Actor, etc.

Also, I learned pretty early in my career (ca. 1972) that some of the biggest botches come from folks not understanding the needs of the users.  I wrote a 10 KLOC PDP-11 assembly language program, based on a 1" thick specification document.  It never got used, because it didn't solve the users' problem.  Fine code, broken spec...

Having said all this, I'm actually quite happy about the fact that Rust is creeping into Linux.  The coding style is likely to be a bit more careful and it may well help to provide some protection against security issues.  (ducks)


  parent reply	other threads:[~2022-02-04  5:12 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
2022-02-03  7:44         ` markus schnalke
2022-02-03  8:18           ` Rich Morin
2022-02-04  2:23           ` Adam Thornton
2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07               ` Thomas Paulsen
2022-02-04 23:18               ` Dan Cross
2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
2022-02-04  5:11             ` Rich Morin [this message]
2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37                 ` Richard Salz
2022-02-04 22:32                   ` Steffen Nurpmeso
2022-02-04 23:05                   ` Thomas Paulsen
2022-02-04 23:15                   ` Seth J. Morabito
2022-02-05  1:41                     ` Adam Thornton
2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
2022-02-04  8:10               ` Steve Nickolas
2022-02-04  8:44                 ` markus schnalke
2022-02-04  9:16                   ` Steve Nickolas
2022-02-04 18:54                 ` John Cowan
2022-02-04 19:45                   ` Thomas Paulsen
2022-02-04 20:28                     ` Hellwig Geisse
2022-02-04 21:03                       ` Jim Capp
2022-02-04 22:30                         ` Steffen Nurpmeso
2022-02-04 22:25                       ` Steffen Nurpmeso
2022-02-06  0:56                       ` Larry McVoy
2022-02-06  1:10                         ` Will Senn
2022-02-06  4:52                           ` Rob Pike
2022-02-06  4:58                             ` Dan Halbert
2022-02-06  5:06                             ` Will Senn
2022-02-06  6:19                             ` Ed Carp
2022-02-06  6:27                               ` Rob Pike
2022-02-06  6:40                                 ` Stuart Remphrey
2022-02-06  6:44                                 ` Bakul Shah
2022-02-06 19:08                                   ` Steffen Nurpmeso
2022-02-06 12:52                                 ` Ralph Corderoy
2022-02-06 13:14                                 ` Ed Carp
2022-02-06 14:13                                   ` Dan Cross
2022-02-06 14:15                                   ` Larry McVoy
2022-02-06 16:31                                     ` Warner Losh
2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:27                                     ` Jon Steinhart
2022-02-06 19:33                                       ` Warner Losh
2022-02-06 19:37                                         ` Jon Steinhart
2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
2022-02-08  5:22                             ` Ed Carp
2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn

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:

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

  git send-email \ \ \ \

* 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.
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 NNTP newsgroup(s).