In my experience, the limitations imposed by the borrow checker actually make you express your ideas more clearly. In this way, you might be fighting the compiler, but when your code does compile, it usually does what you wanted it to (and is also designed in a much better way, since you're forced not to take the easy way to the finish line).
The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
#![nostd] still doesn't handle alternate memory allocators all that well.
My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
> Rust macros are a disaster.
Better than C macros or no macros at all. Could it be better? Certainly.
However, I don't think that Zig comptime is capable of the very important things that Rust macros enable.
> The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).
Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user.
> #![nostd] still doesn't handle alternate memory allocators all that well.
I don't know enough about it to say otherwise.
> My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact.
Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
> We're finding that it's a great replacement for C++, C, […]
So far this makes a lot of sense.
> […] C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.
Well, I see you found a new hammer.
I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.
But that's the cool thing about a hammer. You can use it use it for everything! Even eat soup with it. ;-)
> Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.
But you know that D has a GC by default? You can't be "more memory safe" than that.
> I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.
Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.
The lack of null and using Options instead is one such example.
Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
> But you know that D has a GC by default? You can't be "more memory safe" than that.
First of all, D with GC is not a replacement for C. Anything with a GC is not going to fulfill a systems language role.
Secondly, you can be more memory safe than a GC. Most GCs do not protect against data races, but Rust does. I'm unsure exactly where D falls there.
> Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.
> The lack of null and using Options instead is one such example.
> Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.
Well, sure. But I'm completely unimpressed.
I'm a Scala developer. I have those features available mostly since "forever".
(Modern serialization based on compile time macros is "only" about a decade old, so quite "new" in Scala).
> In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.
They do what they can and the results are OK-isch. But Rust is lacking features. Especially when it comes to abstractions.
Rust would need at least HKTs (higher kinded types) and "context abstractions" ("implicits") to come even close to what's possible in Scala. But Rust type system is still rudimentary in comparison.
Also the meta-programming story is very weak in Rust. I was shocked as I learned that Rust's macros are only on the level of Scheme. That's a shame for a new language, imho.
The only really interesting part about Rust for me is its raw performance. I have to admit that I'm really envious in that regard. (Scala has powerful features but you pay usually a high price for them as the compiler still isn't able to compile that stuff away. The annoying part is that nobody really cares much. They're more concerned with compile times; even Scala compiles at least an order of magnitude faster than Rust).
But actually it's not bad at all that Rust is a small and simple language. It's easy to pick up. (At least if you already know things like HOFs, ADTs, type-classes, Option / Either & Future monads, working with immutable data, and all that).
The other languages with comparable performance are mind twisting and full of bobby traps in comparison. C has no features at all and is outright crazy. C++ has features but that stuff is even more crazy. But Rust is nice and clean! (At least regarding semantics. The syntax is a different story. Rust is one of the ugliest languages. Everything seems patchy and irregular. But OK, that's "only syntax". One gets used to it quite quickly; and they wanted to attract C/C++ programmers, so I can understand why such an ugly syntax was chosen).
> Better than C macros or no macros at all. Could it be better? Certainly.
I don't agree. I'd rather have no macros because that would increase the pressure on the core language and compiler to evolve properly.
Any usage of macros that has to atomize down to the molecules of the syntax tree and then reassemble them from the ground up is screaming Language Failure Here. Those kinds of macros should only exist until the core language either vacuums up the construct and makes it standard or declares the construct verboten at which point they should be excised.
Instead, Rust's procedural macros are spreading like the plague throughout the ecosystem.
> All of your problems with Rust are being worked on.
Unfortunately they're not being completed--which is far more important.
In my opinion:
- Rust is more productive than C
- Rust is easier than C, once you get past the initial bump
And it's not my opinion, it's just fact that Rust has practically the same performance as C.
I say this as someone who is currently actively maintaining embedded firmware with 10,000+ lines of C. It will be my last significant C project.