Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)

["Greg A. Woods" <woods@robohack.ca>]

[-- 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 <rdm@cfcl.com> 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
behaviour.

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

	https://inductive.no/jai/
	https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

  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
times)


BTW, there's also a new scripting language I've got on my stack to
investigate further:

	    https://wren.io

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]