Comment by hyperbrainer
2 days ago
I love Rust, and will continue to use it. But sometimes it feels like "too much". If you have programmed in Rust, you know what I mean. I want to use and experience a language that is to Rust almost like what C is to C++.
This is primarily an educational exercise to see how people find compromises that work for them, and languages in the same space as Rust using alternative strategies.
I've programmed in Rust extensively, and I'm on the Rust language team. I don't quite know what you mean, and I would genuinely like to. If Rust feels like "too much", I'd be interested in knowing what makes it feel that way and how we might be able to improve Rust to avoid that feeling.
Is this something you experience when writing your code, or is this something you experience when reading other people's code?
If it's the former, I'd really love to hear more about those experiences.
If it's the latter, are there particular features that crop up that make code feel like too much?
(To be clear, Rust isn't perfect for everyone, despite our best efforts. And if you want to work with another language, you should! I'm not looking to defend it; your experiences are valid. We'd love to make Rust better, so I didn't want to miss the opportunity to ask, because we so rarely hear from people in the intersection of "I love Rust" and "Rust is too much".)
It's hard to pinpoint the problem, because I love and adore Rust. So, thank you for all the work you have put in -- it's a great language.
I feel like my biggest struggle is simply how hard (tedious?) it is to properly work with generics and some more complex applications of traits. Any time I am working with (especially writing, somehow reading is easier) these, I always take an ungodly amount of time to do anything productive.
I am almost certainly sure this is a skill issue -- I am simply not "Rusting" like I am supposed to. Maybe I overuse generics, maybe I rely on traits too much, maybe I am trying to abstract stuff away too much. But this is one of the reasons I want to also explore other languages in the space, especially ones which make it impossible for me to make this so complex.
Don't get me wrong -- all of this complexity is a joy to work with when I can use my brain. But sometimes, it's just too much effort to do stuff, and it feels like I could be getting away with less. Curiously, I never had a problem with the borrow checker, even though people often complaining about how much it forces them to "stop and think".
Another thing is that C, for some weird reason, always feels "lower level" than Rust, and seeing it gives me some sort of weird satisfaction that Rust does not. Maybe it's just a greener grass syndrome, but wanted to mention it nonetheless.
All this said, I want to just emphasise, that despite this shortcoming (if it even is one), if I were forced to choose a language to spend the rest of my life with, I would not be the least bit sad to only ever use Rust again. I absolutely love it.
> I feel like my biggest struggle is simply how hard (tedious?) it is to properly work with generics and some more complex applications of traits. Any time I am working with (especially writing, somehow reading is easier) these, I always take an ungodly amount of time to do anything productive.
> Maybe I overuse generics, maybe I rely on traits too much, maybe I am trying to abstract stuff away too much.
Is this related to the problem where, if you want to put a generic in a data structure (e.g. an implementation of `Write`), you find yourself propagating a generic bound up an entire hierarchy of data structures and functions using those structures?
Asking because one thing that's common amongst Rust developers is a bit of an aversion to using `dyn Trait` types, and using a `Box<dyn Write>` (for instance) in the right place can wildly simplify your program.
> But sometimes, it's just too much effort to do stuff, and it feels like I could be getting away with less.
The next times you find this feeling arising, please feel free to reach out, if you'd like; I would genuinely love to hear about it. You can reach me by DM on the Rust Zulip, or by the email in my profile.
> Another thing is that C, for some weird reason, always feels "lower level" than Rust, and seeing it gives me some sort of weird satisfaction that Rust does not. Maybe it's just a greener grass syndrome, but wanted to mention it nonetheless.
I was originally a C developer, and I can sympathize. I don't tend to crave that "lower level" feeling often, but for me, there was something satisfying about C in the old DOS days, where you could make a pointer to video memory and scribble on it.
5 replies →
If it's for educational purposes and you want to explore various tradeoffs, then you shouldn't necessarily restrict yourself to languages that make similar tradeoffs regarding safety guarantees in the language as Rust. Again, the goal of writing a memory-safe program is understandable, but there's more than one way to achieve that goal when it comes to language guarantees. That doesn't only apply to languages that offer fewer guarantees than Rust, but also to languages that are possibly less low-level (e.g. OCaml, Nim).
But even for educational purposes, using a language with a poor selection of libraries is likely to lead to a bad experience if what you want to produce is working, non-trivial software. Every project includes some "boring" aspects -- such as parsing configuration and data files -- that you won't necessarily enjoy writing from scratch. The overall programming experience is shaped by much more than the design of the language alone.
You might like Ada as a few people have said. Rust seems kind of niche oriented to me, aimed at programs that for whatever reason don't want to use GC, but ALSO want to use dynamic memory allocation a lot. Ada isn't that great at memory management and mostly aims at embedded programs with fairly simple (maybe just one-time static) memory allocation. In other regards though, it's safer and in some ways simpler than Rust, from what I can tell.
I do not see any serious contender to C. And considering that most people developing alternative languages that aim to replace C do not seem to have a good understanding what makes a good system programming language, I also do not see this changing soon. Tooling for memory safety will improve and I expect we will also have something complete in ISO C at some point. But already today, one does not have to write modern C as your parents did, e.g. there is no need to do unsafe pointer arithmetic and many other unsafe features can simply be avoided. Signed integer overflow can be checked at run-time. Only temporal memory safety is missing a good solution that ensures safety, but I do not find this is to be a major problem in my projects (with some discipline about pointer ownership)
Isn't C++ already a serious contender to C? It clearly has not replaced C everywhere, but it's taken over much of C's market. And if C++ could do it, I don't see why another language couldn't do the same (that's not to say that the next language to do that already exists today).
One thing that's important to notice, I think, is that low-level languages' combined market share has fallen sharply since the 1970s, and it doesn't seem that the trend is about to sharply reverse direction. To me that suggests that if a low-level language wants to be more popular than C++, it should focus on low-level programming and shouldn't try to also be a good applications programming language (as C++ has tried to do that, but the overall market share of C and C++ is lower now than it was in, say, 1990), but I could be wrong about that.
I guess this depends on what you consider a contender. Certainly C++ has taken market share from C and Rust will do to. But I do not think these languages are able to replace C.
You can always break out of the too rusty side and use unsafe tastefully.
UnsafeCell I find particularly useful to exponentially decrease the amount of boilerplate needed to convince the compiler that your code is safe.
Rust can feel like "too much" at times. It's a very feature rich language. But that doesn't mean you have to use every feature. With all feature-rich languages I think that's good advice, since code that does use every single feature often ends up being an unreadable mess. Each feature is there for a certain use case, not for every use case.