:-) I've been around in the industry long enough to know there is no perfect tool. Rust itself has reasonably decent foundations, and fills a niche that was missing for me for a long time. There are no mainstream-acceptable alternatives to C++ for (GC-less) systems level programming that bring in a reasonably modern (ML-ish) type system, pattern matching, proper modules, etc.
However, I also think the vast majority of Rust projects out there right now are using the wrong tool. They're using Rust to write web services and web sites, and the developers are coming from places like NodeJS, TypeScript, etc. It'd be fine, but it's I believe pushing the emphasis in the Rust language community in that direction.
I worked for years in the relatively sane subset of C++ that we used at Google. It's fine, I have to do C++ here and there for work, and I could even go back to it if I had to. But I mostly like Rust, and would miss it. Zig made some decent choices, but others I don't necessarily agree with, but I'd consider it for embedded or low-level dev of various types
> However, I also think the vast majority of Rust projects out there right now are using the wrong tool.
Of course they are, same as what had happened with (to) C++. And the people that use Rust (or C++) because it's "fast" are mostly the same that write code which would be faster if it would have been written in Go, Java (Kotlin?), or C#. I guess every generation of programmers must make the same errors.
Yeah, I've been around this block many times. I've been in the industry since the mid-90s. The problem comes down to that people have all sorts of different motivations in why and how they use technology, and organizations and projects are difficult ships to steer, and the palette of available choices is not always what we want.
I prefer not to consider other people as ignorant or stupid. They just have different motivations or reasons.
But back to the topic: I do think Cargo should have started from looking at Maven as an engineering foundation rather than NPM. Maven shipped from the start with solutions to many of the problems that Cargo is sick with because they were not considered.
> I prefer not to consider other people as ignorant or stupid. They just have different motivations or reasons.
Oh, I didn't want to imply people are stupid, after all, I (and many other people) made the same error 25 years ago.
But talking about Cargo (the last time I used Java there had been no Maven yet), the packages really need at least some sort of namespaces. But I don't think that (newer) languages without a really "battery" standard library can evade the problems of "too many transitive dependencies".
Yeah I agree in principle. There's lots of people who defend it but I think it is a mistake for the Rust stdlib to be missing a lot of quite basic common stuff (random numbers, sha256, md5 are obvious ones to me for example.) They could even break said lib up (stdlib, stdlib-ext, stdlib-embedded) if necessary. But status quo is just inviting future disaster in my opinion.
And don't get me started on the async story. Yikes. Rust is the language that Tokio ate.
However, I also think the vast majority of Rust projects out there right now are using the wrong tool. They're using Rust to write web services and web sites, and the developers are coming from places like NodeJS, TypeScript, etc. It'd be fine, but it's I believe pushing the emphasis in the Rust language community in that direction.
I worked for years in the relatively sane subset of C++ that we used at Google. It's fine, I have to do C++ here and there for work, and I could even go back to it if I had to. But I mostly like Rust, and would miss it. Zig made some decent choices, but others I don't necessarily agree with, but I'd consider it for embedded or low-level dev of various types