From: "Greg A. Woods" <firstname.lastname@example.org>
To: The Unix Heritage Society mailing list <email@example.com>
Subject: Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
Date: Fri, 04 Feb 2022 13:22:02 -0800 [thread overview]
Message-ID: <m1nG61q-003DO0C@more.local> (raw)
[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]
I find programming in Go to be an extremely fun, and usually relatively
easy thing to do, and it's never boring or tedious (though when learning
some new idiom or technique or library it can be challenging, but that's
a good thing).
Maybe writing tests can be tedious at times, but it's also very
satisfying, and quite easy to do with the support in the Go environment.
At Thu, 3 Feb 2022 21:11:14 -0800, Rich Morin <firstname.lastname@example.org> wrote:
Subject: Re: [TUHS] more about Brian...
> 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.
Go's concurrency model was a lot easier for me after I spent some time
working in a C environment that transparently supported working with
either proper threads (with the target system's libpthread as the
underlying implementation) or coroutines (with libcoro as the underlying
implementation). Valgrind was my friend for finding races and other
things one should not do in a threaded program.
> 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.
I find Rust to be appalling and very very very unappealing (to me).
It's C++ for Perl programmers -- and all the bad parts/warts of both.
Rust is, to me, ugly, inelegant, and hard to read and reason about.
I still work on and write lots of C, but I'm very tired of UB. I want a
C-like language (in that it's close the metal/SiO2) and that has
absolutely zero UB in the spec. None. Everything MUST be defined
There are a couple of "new" languages in my sights (for applications
where Go might not be ideal):
- Drew Devault's secret new language: https://drewdevault.com/
- Zig -- http://ziglang.org/ (by Andrew Kelley)
ready and running, apparently. BUT oh, gawd -- it's currently written
in C++ and uses CMake (though apparently comes with its own built-in
build system so that Zig programs don't need anything like CMake, etc.)
- Jai: imperative static/strongly typed C-style language
by Jonathan Loom
No implicit type conversions
No header files
Beautiful and elegant.
Built-in build system.
Jai code can be built on top of existing C libraries
- V -- https://vlang.io
Perhaps the most mature of the lot.
But I would also be happy with just plain old C (though perhaps C99 not
C11), with all the UB caveats nailed down into Defined Behaviour. The
authors and maintainers of modern compilers are not really truly sane.
They most certainly should not be allowed to exploit UB, especially not
behind the user's back as they mostly do now.
C's primitive nature engenders the programmer to think in terms of what
the target machine is going to do, and as such it is extremely sad and
disheartening that the standards committee chose to endanger C's users
in so many ways. As Phil Pennock said:
If I program in C, I need to defend against the compiler maintainers.
[[ and future standards committee members!!! ]]
If I program in Go, the language maintainers defend me from my mistakes.
And I say:
Modern "Standard C" is actually "Useless C" and "Unusable C"
(especially if one does not fully embrace tools like Valgrind and enable
all compiler features that point out UB in all possible ways at all
BTW, there's also a new scripting language I've got on my stack to
Greg A. Woods <email@example.com>
Kelowna, BC +1 250 762-7675 RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Avoncote Farms <firstname.lastname@example.org>
[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2022-02-04 21:30 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
2022-02-04 21:22 ` Greg A. Woods [this message]
2022-02-04 21:37 ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 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
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).