Unfortunately I don't still have the code I was writing to tell you exactly, but the main issue is that you can't write generic functions because some times your usage will need to pass in a reference, some times not. The map and filter functions are examples of this.
My hello world for evaluating a language is this: write a program that sums its arguments. It's arguments might be numbers or strings so you have to filter and cast. It's a simple program but I find it a good indicator of how elegant (in terms of what I consider elegant of course) a language is to use on a daily basis. Lisps obviously do best in this type of test but Haskell also does very well despite it's type system. So the issue isn't types, it's pointers.
> Unfortunately I don't still have the code I was writing to tell you exactly, but the main issue is that you can't write generic functions because some times your usage will need to pass in a reference, some times not. The map and filter functions are examples of this.
Usually you pass references, because that's the most generic option. I wouldn't say "you can't write generic functions", but you sometimes have to add wrappers that convert between levels of indirection.
> My hello world for evaluating a language is this: write a program that sums its arguments. It's arguments might be numbers or strings so you have to filter and cast. It's a simple program but I find it a good indicator of how elegant (in terms of what I consider elegant of course) a language is to use on a daily basis. Lisps obviously do best in this type of test but Haskell also does very well despite it's type system. So the issue isn't types, it's pointers.
Certainly a language can be easier to use and you can write more elegant-looking code if most everything is a reference. No argument there.
It basically sounds like you weren't using the low-level features of Rust, which are important for our use cases but not important for everyone's. So Rust might well not be for you. That's totally fine, as I don't intend for Rust to be the one language to rule them all.
"It basically sounds like you weren't using the low-level features of Rust, which are important for our use cases but not important for everyone's."
But even in a system level program, how often do you need low level features of the language. I think the answer is "very seldomly", and hence, these low level features should be tucked in behind the higher level abstractions. They should be available only when required.
Ruster here, and this is also something that concerns me (I too have run afoul of the map vs filter issue that you mention). We'll need to carefully consider our composable higher-order-function APIs before 1.0.
I think an approach like Clojure's reducers might work, since it's possible to compose several higher-order operations and end up with no extra allocations or loops.
My hello world for evaluating a language is this: write a program that sums its arguments. It's arguments might be numbers or strings so you have to filter and cast. It's a simple program but I find it a good indicator of how elegant (in terms of what I consider elegant of course) a language is to use on a daily basis. Lisps obviously do best in this type of test but Haskell also does very well despite it's type system. So the issue isn't types, it's pointers.