8 Jun
2020
8 Jun
'20
12:16 a.m.
On Sun, Jun 7, 2020 at 5:37 PM Chris Torek <torek(a)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.