rust has, uh, iterators, map, collect, size_hint, automatic coercions to vector, ...
buf: repeat(0).take(cap).collect(),
let's say, just for the sake of argument, Im an imperative c++ systems programmer whose cognitive load is currently at max from grokking the awesome borrow checker. perhaps there could be a slightly easier way to perform a basic task like initializing some bytes on the heap. such as:
buf: Vec::with_fill(size, value)
The issue with creating such functions is that not everyone has the same understanding of what "basic" means. Hence, the interface might grow and grow and grow again with times and you ends up with a lot of duplicate functionalities.
Another way to write this :
(0..size).map(|_| value).collect()
There used to be a Vec::from_elem(size, value), but it was removed not too long ago, in favor of the iterators.
You might want to read the RFC that proposed the change, or take a look at the pull request that removed it.
Speaking of things I've read:
To employ any particularly cutting-edge technologies. Old, established techniques are better.
Lack of practical affordances, too dogmatic about paradigm.
http://doc.rust-lang.org/1.0.0-alpha/complement-project-faq.html
I wouldn't consider iterators to be "particularly cutting-edge technologies". It's true that it takes some time to get used to them, but they are central to the way that Rust's collection APIs work - it's not like you will need to learn them only to initialize vectors and then never use them again.
Also, could you expand on why this particular decision makes Rust seem "too dogmatic about paradigm" to you?
I can't see how one would apply this criticism to Rust, given that it is a multi-paradigm language - there is no enforcement of purism, nor hardcore OO, for example.
could you expand on why this particular decision makes Rust seem "too dogmatic about paradigm" to you?
Because you apparently have to know functional b*shit to initialize 4K bytes on the heap with zeros, and figure out what size_hint does wrt vector capacity? I don't care at all about functional style or closures for systems programming. Literally the one thing I find interesting about rust is the borrow checker. And it has great FFI with C for gradual migration.
If I want to write stuff thats magic and abstract I use python. Also @joris I'm sure you would like the c++ std::string class. It's so pure and generic, and totally useless compared to a batteries included one like python. But hey you can get iterators to it.
PS is rust missing memmem() too? e.g. search for a subsequence of bytes in a byte slice. I looked and failed and had to write my own horribly unoptimized version.
Just because it has a different API does not mean its bad. It just means you do not know it.
i think this is a reply to renato? sorry, unintentional reply.
Its not functional bullshit (welcome to the internet, where you can curse). Rust does things differently than C++, if it did things the same as C and C++, we would still be in 1980.
If you want shitty abstractions, along with nonorthogonal and bloated APIs, go back to C++.
It is a new language, do not treat it like an old language.
My opinion is that something like batteries doesn't fit in the stdlib. I see the stdlib like a building block. Now if you want convenient wrappers for this sort of thing, you (or anybody else) could write a Vec_utils libs using the "abstract" constructs from the stdlib to provide such a functionality and ship it in crate.io. The way i see it is that it's not core functionality but a different API. I'm not speaking for the rust team, but like i said i think that if the stdlib was trying to satisfy everyone's view of "what a good api is", it would become a mess. The trend has been to remove most of custom functions to provide abstract generic constructs instead. I personally think it's a good idea, because the constructs are here, and writing wrappers is much easier than writing new constructs from scratch.
Now, regarding memem(), that's a different topic. In this case, it's not an issue with the API, and providing a generic implementation of something like Knuth morris pratt on iterators is actually a good idea, and a nice feature. You might consider opening an issue :).
I think this is a valid concern.
Vec is the central collection of the language, and we should give it sugar, more methods to make it easy to use. Vec::from_elem is a good example.
For completeness, the vec! macro does partly take over after Vec::from_elem in the following situation: vec![elem; N] is implemented if elem is Copy and N is a compile time constant.
Rust is a different language from C++ and has different idioms. Iterators are a very common language idiom that you should not try to avoid if you want to write in Rust.
Also, your tone is very hostile.
repeat(0).take(N).collect() seems to be quite a bit slower. Is it possible to fix that? If not, from_elem seems useful.
Here's my proposed evidence: bench-times · GitHub --- is that a fair benchmark?
It is slower and this is very much a known problem that's currently being worked on: The Trusted Iterator Length Problem - Rust Internals
@kjpgit, please try to keep your criticism reasonably civil. @sinistersnare, while you're in the right here, continuing with more mean-ness just spreads more mean-ness, please try to chill a bit as well.
While that's a totally valid perspective, it does mean you're going to end up fighting with the standard Rust idioms, as they take lots of inspiration from these kinds of languages. Note I said 'inspiration,' for example, our closure system is very different from other languages, because systems languages have certain requirements.
While orthogonality, abstractions and everything are good in general, this particular case really looks like a nonsense.
I would expect a negative (and emotional!) first reaction on it from most of C/C++ programmers - not exactly the thing Rust needs for adoption. (And that's even without talking about the trusted iterator problem with unclear solution.)
I'll say the same thing as I said to @kjpgit: please keep your criticism constructive and substantive.
Personally I don't see a problem. If syntax is ugly write a macro sugar.
You won't be able to deal with collections without it.
A friendly piece of advice: If you actually want your ideas to show up in the language or libraries, you should adopt a different approach ... in particular, "I don't care", "the one thing I find interesting", and "If I want ... I use" is not effective.
Realtalk vec![0; 1000] works if you just want some compile-time-constant-known-sized bytes on the heap.
But yeah from_elem is a highly demanded sugar. I expect we'll re-introduce it post-1.0 at worst. There's something to be said for keeping the 1.0 release completely minimal, though.
There's another way to look at it: the need to fill 4K with an uninteresting value may indicate that something somewhere is done in a wrong way. Rust just makes the redundancy apparent.