> What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns.
Which would look a lot like... Rust!
Which would look a lot like... Rust!
I want Rust, but without panics, without generics (aside for lifetimes), without traits and bounds (aside for lifetimes), without operator overloading, without methods on structs, without RAII, without iterators, etc.
I don't see that as a necessarily bad thing, it brings uniformity with the rest of the functions. I've coded with libraries like APR, Nginx's API, and GTK's GLib, and the result looks quite aesthetically pleasing too (subjective of course).
I'm also not considering this as a deal-breaker or anything. The point is not that this one particular feature makes a language complex, but rather that features like these tend to pile up, and what once looked like a simple language quickly becomes less simple due to dozens of such simple features added together. But one or two of these is fine.
'5'.is_digit(10) // Is literally the same as
char::is_digit('5', 10) // this
Rust even has guidelines recommending you consider e.g. &self rather than having an associated function whose first argument has type &Self, but noting that you should not do this if your type has "smart pointer" behaviour where users expect to call methods on the inner value instead. For example Box and Arc provide associated functions but not methods.
And that makes it very difficult to understand the performance of your code. Just a few days ago I couldn't wrestle the compiler into unrolling a loop (because of a get_unchecked that was hard to reason about), dropping performance of the entire data structure to as little as 30% of a quick proof of concept implementation. The asserts are powerful tools, but only if you can figure out why the compiler is not behaving nicely and how to construct the conditions that will convince it...