On Sun, Jun 7, 2020 at 5:37 PM Chris Torek <torek@torek.net> 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<T>` 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.