From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1148 invoked from network); 7 Jun 2020 22:17:48 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jun 2020 22:17:48 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 835759C872; Mon, 8 Jun 2020 08:17:41 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 11C609C5F8; Mon, 8 Jun 2020 08:17:16 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="kO51Yg8G"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 80E919C5F8; Mon, 8 Jun 2020 08:17:14 +1000 (AEST) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by minnie.tuhs.org (Postfix) with ESMTPS id EE1469C5E5 for ; Mon, 8 Jun 2020 08:17:13 +1000 (AEST) Received: by mail-qk1-f174.google.com with SMTP id q8so15524270qkm.12 for ; Sun, 07 Jun 2020 15:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tjSr5SUjqqj1zh8nlDCNdKbwiqiuvEwRTd2NKcSd3TY=; b=kO51Yg8GMYeWPd3IQxIatZ/NfXchy7pOzeFgEggwP0gDiBZdUkXqMMIM63CRHzoPIp QWI1snJ7CFq72mby3Y+Ckfml9LE1vXPsJh87YvmehWw19i+mIScltCqae54Vm6BgzG2p +tkoTMz7Lu2tCV2/nTeqVmOe9PA++QDPjvHsr6prdp2yE0tbWIsy3f5+M/3IxsGKMs4I hbtV/Cz21G70oJIiRQ/qP2akhrcmDogbaIVVGtmmZmlE6i84TGQ3X8RNL9ZpukzClsH1 17BCtlh1Iti/DU/RCU/8cG1dVBhKF92MOFKzVTU0IBKEqA3ZVfE8LcDar07VupjwqkFG EiBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tjSr5SUjqqj1zh8nlDCNdKbwiqiuvEwRTd2NKcSd3TY=; b=hAKGQv570T04m9BX2PeVoQCv7tk1EvoesDpgW+KP1O6+RushBUD5TedIzIhSw7QpES Jnzkg40JImX2hfRGsyLFyNvIP70Exe7Z+Yydghwhf3UlfjtCm/L4wBQxNpC+5KX11QPs Qbx4+bvtVrN/rebY9v7dk2zMEPtb3kQKQ3ItrNuCTDar8YCoV5dNr4etWZ2CJT1FiZa3 Sc0vgBox8EXKOsnl7/wikFDuzrsu8l2+hZzFyG+2J6c34MlaCbUjm70INGckhKwqlLaI teDjbmRGZJVzz5KXRKAKhCPnuGpw4uKcZfOaBUWbkc/SRPjBTl540q9I5MWJKUMQY9X1 qmuA== X-Gm-Message-State: AOAM531QRtecoVYE6nvIWAVe+iuA06NZ3Qbmv8hlT6eL3fSnORGX4mIK sh8314xxh4d8mhwSCExuhN+j6QNnMk+I3gEpa7LAIwWK X-Google-Smtp-Source: ABdhPJxzymo5t0Jzk1DF86er/cBrCpwmU9Dft+cC8sTp8yoBRqnpx5f4bNwXUDQH1QX7yNI0Kd6VDO53DTiuhXcrg1w= X-Received: by 2002:a37:ef18:: with SMTP id j24mr16804622qkk.380.1591568232976; Sun, 07 Jun 2020 15:17:12 -0700 (PDT) MIME-Version: 1.0 References: <17d519b0-384c-fddd-9fe1-700bbe9821be@gmail.com> <202006072115.057LFV6v089953@elf.torek.net> In-Reply-To: <202006072115.057LFV6v089953@elf.torek.net> From: Dan Cross Date: Sun, 7 Jun 2020 18:16:36 -0400 Message-ID: To: Chris Torek Content-Type: multipart/alternative; boundary="00000000000029964405a785db37" Subject: Re: [TUHS] History of popularity of C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000029964405a785db37 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 7, 2020 at 5:37 PM Chris Torek wrote: > Yes, both Rust and Go are being used. > Indeed. The languages complement each other quite nicely. Disclaimer: I've been programming in Rust for my day job for almost two years now and I sit in the office next to the Go tech lead and in close proximity a number of people working on Go. Rust has some advantages: like C++, it can compile to very fast > code that does not need a garbage collector but that provides > type-safety. It also gives you thread-safety through clever > compiler analysis of who "owns" any given variable or data. > Safe Rust code is data race free, but not free of race conditions, let alone thread safe in all ways. The ownership / lifetime-analysis / borrow-checker is quite > complicated and takes a lot of getting-used-to. Once you get used to it, it doesn't feel that complex but yes, it takes a while to get used to. When we switched our project to it (from C++, at my behest) our tech lead quipped that Rust has a "near vertical" learning curve. Suffice it to say we're all quite glad we switched but there was an adjustment period. Interestingly, we find it a selling point for attracting new engineers regardless of the challenges in coming up to speed. [snip] Rust has, or at least had, rather bad > array support when I last looked at it: you could make an array > out of any type, but with only up to 32 elements. I'm afraid this is incorrect. Rust arrays are indexed by a `usize`, which is basically whatever `size_t` would be in C. Rust arrays in general can be essentially arbitrarily large (up to limitations imposed by the target machine, of course). However, Rust does not support dependent types, most certainly not for arrays. In other words, an array's size is considered part of its type and so when specializing traits on arrays, one must do so explicitly for each supported array size. For practical reasons such implementations are often limited to a relatively small number of distinct sizes; 32 is a believable number. Perhaps that's what you're thinking of? For example, the `Vec` type was recently modified to implement the `From` trait on arrays, but only on arrays up to size 32. This means that one can essentially create a dynamic, growable vector seeded from an array, but such source arrays are limited in how large they can be. My current biggest frustrations are in assumptions made by the memory allocator, the magical nature of `box` (the allocation primitive), and the under-defined memory model. - Dan C. --00000000000029964405a785db37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 7, 2020 at 5:37 PM Chris Tore= k <torek@torek.net> wrote:
=
Yes, both Rust and Go are being used.

Indeed.=C2=A0 The languages complement each other quite nicely. Disc= laimer: I've been programming in Rust for my day job for almost two yea= rs now and I sit in the office next to the Go tech lead and in close proxim= ity a number of people working on Go.

Rust has some advantages: like C++, it can compile to very fast
code that does not need a garbage collector but that provides
type-safety.=C2=A0 It also gives you thread-safety through clever
compiler analysis of who "owns" any given variable or data.

Safe Rust code is data race free, but not fr= ee of race conditions, let alone thread safe in all ways.

The ownership / lifetime-analysis / borrow-checker is quite
complicated and takes a lot of getting-used-to.

=
Once you get used to it, it doesn't feel that complex but yes, it = takes a while to get used to. When we switched our project to it (from C++,= at my behest) our tech lead quipped that Rust has a "near vertical&qu= ot; learning curve. Suffice it to say we're all quite glad we switched = but there was an adjustment period.

Interestingly,= we find it a selling point for attracting new engineers regardless of the = challenges in coming up to speed.

[snip]=C2=A0 Rust has, or at least had, rather= bad
array support when I last looked at it: you could make an array
out of any type, but with only up to 32 elements.

I'm afraid this is incorrect.=C2=A0 Rust arrays are indexed by a= `usize`, which is basically whatever `size_t` would be in C. Rust arrays i= n general can be essentially arbitrarily large (up to limitations imposed b= y the target machine, of course).

However, Rust do= es not support dependent types, most certainly not for arrays. In other wor= ds, an array's size is considered part of its type and so when speciali= zing traits on arrays, one must do so explicitly for each supported array s= ize. For practical reasons such implementations are often limited to a rela= tively small number of distinct sizes; 32 is a believable number. Perhaps t= hat's what you're thinking of?

For example= , the `Vec<T>` type was recently modified to implement the `From` tra= it on arrays, but only on arrays up to size 32. This means that one can ess= entially create a dynamic, growable vector seeded from an array, but such s= ource arrays are limited in how large they can be.

My current biggest frustrations are in assumptions made by the memory allo= cator, the magical nature of `box` (the allocation primitive), and the unde= r-defined memory model.

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Dan C.

--00000000000029964405a785db37--