Four Years of Rust

I really want to like Rust, and I've made a few attempts in the past to get involved - I wrote a database driver for a time series database (KDB) in pure Rust among a few other things. I've even done a couple deep dives into rustc to figure out the cause of some iterator slowness (it wasn't giving proper hinting in the LLVM IM).

However, I keep having to step back. And in this short time Rust has progressed a lot (and that isn't entirely a good thing either).

Rust might be the most liked language, but that is mostly a measure of how vocal its supporters are. It is also very underused for how liked it is. It is become a C-like Haskell in that people like it a lot, but don't use it for much important. Like Haskell, it might turn out to be a great research language, but not be used much in practice. I was hoping to see a language that was much more practical.

I'm about to take another shot at Rust, and I decided this time I should just ignore all the dislike of `unsafe` and just use it as much as I need to. I think I was making life more difficult on myself by trying to avoid it so much, but when you have a lot of pointers that have multiple refereces between then, you kind of have to. Doulble linked and mutually linked structures - where any pointer chance can lead to a mutation - are Rust's achillies heel. Unfortunately, you see that a lot in system-level programming. I write a lot of high performance code and low-latency networking. My main reason to use Rust is for performance reasons and a language with fewer footguns than C++., but something that doesn't completely remove my ability to produce good code.

However, I think Rust has moved too fast in the language department. It has changed and continues to change at a pace that prevent people how mainly use it as a tool for other things from becoming an idiomatic writer of the language. The idioms change too quickly.

The networking stack for efficient non-blocking event driven code still isn't where it needs to be. In Java for example, the NIO abstractions are much better. C++ just turns you over to the C system API. Rust is a disaster in the middle with kind of having a socket abstraction and telling you to just use libc for the rest. This has been an issue for years. Tokio is the wrong abstraction on the wrong level for me, and mio underlying library is kind of a mess with its token architecture, how it handles user defined events. Hopefully it has improved in the last couple years. It used to be slower than it needed to be.

"Slower than it needs to be" can describe a number of things in Rust, also the default hash implementation. Why would you use a secure hash for your default? If you really need that, you know you do, and 99.999% of the uses cases don't need that. I often need small key performance, which is basically the trade off they decided against.

C++ has blown its complexity budget a 100x over. Rust: hold my beer. In just a few year, Rust has kept up to c++ in that measurement (again, not a good thing). I'd like the language to stabilize a bit and work on what is currently there instead of running off to add support for yet another programming paradigm (async and userland threads - feel like a trip back in time to 20 years ago).

Side note on docs formatting: Reading the documentation is still incredibly difficult for me. It doesn't flow well, the top of the page has no index - you basically just have to scroll down. The page width is fixed to 960px so there are interior scroll bars on the code segments. No use of background color is mostly white so it is a big mess of black on while with some small indentation differences. Look at cppref and cpluplus: both have essentially broken down contents at the top making it easier to find what you are looking for, they both make use of color effectively. And everything on Rust Docs starts off fully expanded: you don't actually expand what you want to see instead of have to fold what you don't want to see (so first thing on every page, I have to immediately fold everything, then unfold the often too long context section). Seems backwards to me. And navigation on ther two sites is much better once you get deep on the docs. You can't go to a rust page doc and skim down a page or two looking for the call you want (e,g.: I need to find the mutating calls on a tree). On the cpp docs on both sites very eary, on rust it is tough. There is no "here are all the lookup methods" and "here at all the methods to look things up"

It's funny, I give almost the exact opposite advice when I'm helping Rust newbies. My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes.

w.r.t. Arc/Rc, I'd say that it might feel verbose at first, but it makes explicit what a GC does implicitly, and you can get all the benefits of Rust's ownership model at the same time. I can pick and choose when to rely on the GC and when to explicitly manage lifetimes myself. That's really cool! I maybe a bit weird in this, but I like complexity to get surfaced so I can't pretend it's not there.

What do you mean by:

> Its (thread-local) memory heap is GC'd by default.

What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

Not to be the nay sayer here, but garbage collection kind of goes against the premise of Rust, as stated by the mission statement. I'm a fan of Rust, but I also like Python, but they are different tools for different problems. Go seems like the tool for your specific problems. I'm not trying to be offensive towards you, or anything, but Rusts mission statement was written pretty clearly and the reasons against a garbage collection were laid out reasonably. It's a systems language, meant to be along the lines of C or C++. Used for close to the metal projects, like operating systems, or drivers (ostensibly), where a garbage collector is going to have a debilitating effect as cycles and efficiency are very necessary. The compiler is the checker, taking the place of the garbage collector (sort of).

swift is the language you're looking for. unfortunately it's pretty much only useful for ios dev.