The API used to be what you suggest, but it was changed because it forces doing a new allocation for each line. By taking a mutable string, code can reuse the backing storage of a string (or append to an existing one), which is especially useful for efficient loops.
> Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.
That's definitely a valid sentiment, but I think a better framing would be "isn't ready for use in non-low-level contexts": Rust is (and aims to become even better) an enabling technology that allows higher level programmers to more easily write performance sensitive code, because the aggressive compiler checks help people sidestep days/weeks of subtle pointer pain. Of course, the language focuses on this low-level/performance-sensitive space, and other languages may make more sense if those benefits aren't important for your particular use case.
I'm not saying that the possibility of doing it the current way should be removed, I'm just saying that there should be a cleaner/easier way that's recommended in the Rust docs. If people really need to optimize this that's fine, but it should be opt-in, not the only way to do it.
> If people really need to optimize this that's fine, but it should be opt-in, not the only way to do it.
Be careful, you're taking goals of other languages and layering them on Rust. It's entirely valid for a language to decide that the default idioms should not be sub optimal where that's easily achievable. In a language meant to compete with C/C++ on performance, defaulting to a slower idiom when security is not in question may not be the correct choice. In a language that is accepting some level of non-negligible performance loss in idiomatic code already (such as Go), the decision may be different.
Valid point. My perception is that Rust wants to be a little more mainstream than C++ though.
That said, my conclusion after looking at Rust is that it's Haskell for compile-time memory management; i.e. it won't become very popular, but it'll influence languages that do.
I'm not entirely sure what you mean by "a little more mainstream", which I read as implying C++ isn't mainstream, and when I think mainstream programming languages the top two in my mind, when generalizing across domains, are C/C++ and Java. There are specific areas where they aren't somewhere very close to the top (webapps, but even there Java makes a showing in the enterprise), but those are the exceptions.
My impression of Rust has always been that it's trying to supplant C++, by providing something with similar performance characteristics while being safer and with somewhat improved ergonomics (given the required complexity increase for the additional security, which may yield a net gain or loss in ergonomics depending on your point of view and background).
> it won't become very popular, but it'll influence languages that do
That's entirely possible, and I'm willing to accept that as a good thing if it happens. :)
> Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.
That's definitely a valid sentiment, but I think a better framing would be "isn't ready for use in non-low-level contexts": Rust is (and aims to become even better) an enabling technology that allows higher level programmers to more easily write performance sensitive code, because the aggressive compiler checks help people sidestep days/weeks of subtle pointer pain. Of course, the language focuses on this low-level/performance-sensitive space, and other languages may make more sense if those benefits aren't important for your particular use case.