The borrowchecker is what I like the least about Rust

Well, I have read TFA.

The author may have a point in the idea of borrowing record fields separately. It is possible if we assume that the fields are completely orthogonal and can be mutated independently without representing an incorrect state. It would be a good option to have.

But a doubly-linked list (or graph) just can't be safely represented in the existing reference semantics. Dropping a node would lead to a dangling pointer, or several. An RDBMS can handle that ("on delete set null"), because it requires a specific way to declare all such links, so that they can be updated (aka "foreign keys"). A program usually does not (Rc / Arc or shared_ptr provide a comparable capability though).

Of course a bidirectional link is a special case, because it always provides a backlink to the object that would have a dangling pointer. The problem is that the borrow checker does not know that these two pointers belonging to different structs are a pair. I wish Rust had direct support for such things, then, when one end of the bidirectional link dies, the borrow checker would unset the pointer on the reciprocal end. Linking the objects together would also be a special operation that atomically sets both pointers.

In a more general case, it would be interesting to have a way to declare some invariants over fields of a struct. A mutual pair of pointers would be one case, allowing / forbidding to borrow two fields at once would be another. But we're far from that.

Special-casing some kinds of pointers is not unheard of; almost every GC-based language offers weak references (and Java, also Soft and Phantom references). I don't see why Rust could not get a BidirectionalRef of sorts.

Until then, Arc or array with indexes seem to be the only guaranteed memory-safe approaches.

Also, in the whole article I could not find a single reason why the author chose Rust, but I suppose it's because of its memory efficiency, considering the idea of keeping large graphs in RAM. Strictly speaking, Go could be about as efficient, but it has other inflammation points. C++... well, I hope Rust is not painful enough to resort to that.

I remember very well one of the first public presentations about Go. It focused heavily on goroutines and channels and included a live demonstration of pushing an element through one million channels. It also included a demo of spinning up three racing queries to the Google search engine using the select statement, and picking whoever returned first. it was all about the new cool feature. They also had TCP-over-channels and eventually had to remove that because the model didn’t fit.

Nobody may have known they cared about Erlang, but those features sure made people pay attention.

The lamentations I usually hear about errors in Go are that you have to use a product type where a sum type would be more appropriate, and that there isn't a concise syntax analogous to Rust's ? operator for the extremely common propagate-an-error-up-a-stack-frame operation, not that you have to declare errors in your API.

Also, in my experience, the Rust maintainers generally err on the side of pragmatism rather than opinionatedness; language design decisions generally aren't driven by considerations like "this will force junior developers to adhere to the right discipline". Rust tries to be flexible, because people's requirements are flexible, especially in the domain of low-level programming. In general, they try to err on the side of letting you write your code however you want, subject to the constraints of the language's two overriding design goals (memory safety and precise programmer control over runtime behavior). The resulting language is in many ways less flexible than some more opinionated languages, but that's because meeting those design goals is inherently hard and forces compromises elsewhere (and because the language has limited development resources and a large-but-finite complexity budget), not because anyone views this as a positive in and of itself.

(The one arguable exception to this that I can think of is the lack of syntactic sugar for features like reference counting and fallible operations that are syntactically invisible in some other languages. That said, this is not just because some people are ideologically against them; they've been seriously considered and haven't been rejected outright, it's just that a new feature requires consensus in favor and dedicated resources to make it happen. "You can do the thing but it requires syntactic salt" is the default in Rust, because of its design, and in these cases the default has prevailed for now.)

OCaml lacks Rust's ecosystem support. Also, I personally found it ugly, although this is admittedly subjective and also kind of petty.

Writing Elixir for a living is seemingly a growing trend.