I evaluated Rust a couple of months ago and had to reject it because it's pointy nature makes it difficult to write high order functions.
Pointers in Rust: a guide
11–20 of 33 posts
Re: Pointers in Rust: a guide
#12I evaluated Rust a couple of months ago and had to reject it because it's pointy nature makes it difficult to write high order functions.
What language did you choose in the end?
Re: Pointers in Rust: a guide
#13I'm glad that this guide emphasizes avoiding pointers by default. One of the emerging trends that we've noticed for new users is to allocate on the heap far too often when they could be allocating on the stack instead. I'm also glad that this emphasizes the return-value optimization that Rust uses to make returning a pointer unnecessary. However, Steve, I wish you hadn't mentioned managed pointers at all. :P Overuse…
I'm still pretty unexperienced with the language so take this with a grain of salt, but I think one of the reasons people allocate on the heap is because it is so tempting to write functions that accept borrowed pointers as arguments, due to the flexibility of taking either borrowed or managed pointers. However, when you want to call the same function using a stack variable, you have to change your call invocation or the function, which is just an extra pain whenever you want to refactor.
For example:
fn foo(a: &int){
a.do_something()
}
fn main(){
let a = @5;
let b = ~5;
let c = 5;
foo(a);
foo(b);
foo(c); // ack!
//laboriously hunt down all my invocations
foo(&c); //much better
}Re: Pointers in Rust: a guide
#14Re: Pointers in Rust: a guide
#15I evaluated Rust a couple of months ago and had to reject it because it's pointy nature makes it difficult to write high order functions.
What made it so hard? I'd be interested in hearing more.
Re: Pointers in Rust: a guide
#16I evaluated Rust a couple of months ago and had to reject it because it's pointy nature makes it difficult to write high order functions.
What made it so hard? I'd be interested in hearing more.
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.
Re: Pointers in Rust: a guide
#17So I don't speak Rust, but if succ takes a pointer then yes you do need to pass it a pointer, and that's what referencing is doing, right? Not that referencing a stack variable is hard...
Re: Pointers in Rust: a guide
#18I'm glad that this guide emphasizes avoiding pointers by default. One of the emerging trends that we've noticed for new users is to allocate on the heap far too often when they could be allocating on the stack instead. I'm also glad that this emphasizes the return-value optimization that Rust uses to make returning a pointer unnecessary. However, Steve, I wish you hadn't mentioned managed pointers at all. :P Overuse…
I'm still pretty unexperienced with the language so take this with a grain of salt, but I think one of the reasons people allocate on the heap is because it is so tempting to write functions that accept borrowed pointers as arguments, due to the flexibility of taking either borrowed or managed pointers. However, when you want to call the same function using a stack variable, you have to change your call invocation or…
First I just want to point out that you're not allocating on the heap just by using references. This:
let x = &1;
let x1 = 1; // allocated on the stack
let x = &x1; // reference to a stack allocation
As for the pain of refactoring your code to move from heap-allocations to stack-allocations, this is exactly why we're so fervent to encourage people to use stack-allocated values from the get-go. :) We're fans of Python's philosophy of making things explicit, which explains why we're different from C++ in this particular detail (i.e. we make you explicitly acknowledge when you're passing a reference to a function that expects a reference).
Re: Pointers in Rust: a guide
#19Earlier quoted context omitted.
What made it so hard? I'd be interested in hearing more.
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 fi…
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.
Re: Pointers in Rust: a guide
#20Earlier quoted context omitted.
What made it so hard? I'd be interested in hearing more.
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 fi…
> 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.