Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointers in Rust: a guide

words.steveklabnik.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Pointers in Rust: a guide

#21

Post by ww520 »

kibwen wrote: post #7

I'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…

Managed pointers are fine. The only problem I see is ~str and ~[] are managed pointers most of the time and that makes the code looks weird to people.

If we make str default to managed rather than ~str, and [] default to managed rather than ~[], most of the weird pointer complaints will go away.

Edit: Darn, what was I thinking? I meant owned pointer.

Strings or vectors are owned in most cases. That makes Rust code littered with ~str or ~[], especially when having vector of strings or vectors of vectors. ~[~[~str]]. If we make str and [] default to owned, the code would be much cleaner.

That means move the syntax for fixed vec to something else, like ![1,2,3]

Re: Pointers in Rust: a guide

#22

Post by pcwalton »

ww520 wrote: post #21
kibwen wrote: post #7

I'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…

Managed pointers are fine. The only problem I see is ~str and ~[] are managed pointers most of the time and that makes the code looks weird to people. If we make str default to managed rather than ~str, and [] default to managed rather than ~[], most of the weird pointer complaints will go away. Edit: Darn, what was I thinking? I meant owned pointer. Strings or vectors are owned in most cases. That makes Rust code li…

I'm not sure what you mean. "String literals" are &str, not a managed string, and [1, 2, 3] syntax creates a fixed-length vector, not a managed one.

Re: Pointers in Rust: a guide

#23

Post by kibwen »

ww520 wrote: post #21
kibwen wrote: post #7

I'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…

Managed pointers are fine. The only problem I see is ~str and ~[] are managed pointers most of the time and that makes the code looks weird to people. If we make str default to managed rather than ~str, and [] default to managed rather than ~[], most of the weird pointer complaints will go away. Edit: Darn, what was I thinking? I meant owned pointer. Strings or vectors are owned in most cases. That makes Rust code li…

Neither ~str nor ~[] are managed. Neither of those introduce any runtime overhead.

Re: Pointers in Rust: a guide

#25

Post by earlz »

I've been learning Rust officially for about a week. I wish this had made it on hacker news last Friday!

I'm learning by making a little MVC framework with cgi-bin (eventually it'll be portable to rust-http and elsewhere..). The best part about Rust is that in 99% of cases, if your "logic" is right, and your code compiles, everything will just work and run properly. Unlike in C where your logic may be right, but your pointers wrong, or in C# where your logic is right, but that threw a null reference exception, etc.

The hard part was that I tried writing Rust like I do C#. Using garbage collection elsewhere. The biggest hurdle is that when you're designing your structures you must not think just about what they need to access. You must also think about the ownership of what they access, and the ownership of what will be using it.

After finally refactoring and figuring out my ownership model, turns out I didn't even need garbage collection or reference counting. Everything could go onto the stack save for some vectors and mutable strings

Re: Pointers in Rust: a guide

#26

Post by lucian1900 »

kibwen wrote: post #19
Touche wrote: post #16

Earlier quoted context omitted.

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.

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.

Re: Pointers in Rust: a guide

#27

Post by steveklabnik »

earlz wrote: post #25

I've been learning Rust officially for about a week. I wish this had made it on hacker news last Friday! I'm learning by making a little MVC framework with cgi-bin (eventually it'll be portable to rust-http and elsewhere..). The best part about Rust is that in 99% of cases, if your "logic" is right, and your code compiles, everything will just work and run properly. Unlike in C where your logic may be right, but your…

Hopefully future new learners will have it easier. :)

If there's anything else that's confusing that could use elaborating, let me know.

Re: Pointers in Rust: a guide

#28

Post by andrewflnr »

Touche wrote: post #14
tinco wrote: post #12

Earlier quoted context omitted.

What language did you choose in the end?

Lua

What kind of project was it that both Lua and Rust were in the running? Those are pretty much on opposite ends of spectrum, at least the spectrum of imperative languages with functional parts.

Re: Pointers in Rust: a guide

#29

Post by cpeterso »

steveklabnik wrote: post #8
kibwen wrote: post #7

I'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 wish you hadn't mentioned managed pointers at all I originally wrote this as an official guide, so I needed to talk about them, and then I got lazy, and just posted it after the PR got closed. But yes, discouragement is the right approach. > We need more articles like this to combat the "oh rust is so complicated it has 200 DIFFERENT TYPES OF POINTERS" propaganda. Exactly. The problem is that pointers are one of…

I'm not sure why people think Rust pointers are so confusing. Any C++ developer familiar with shared_ptr and unique_ptr should understood Rust pointers almost immediately.

The area of Rust that I find most confusing (and sends me back to the documentation and example code every time) is the module system and the relationship between library crates, modules, files, and identifier paths. :\

Post reply on HN