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

Four years with Rust

words.steveklabnik.com

Post reply on HN
Print view View original

51–60 of 199 posts

Re: Four years with Rust

#51

Post by steveklabnik »

amelius wrote: post #47
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

To be clear, RefCell does not do reference counting, Rc does. RefCell does runtime borrow checking.

Re: Four years with Rust

#52

Post by kazagistar »

amelius wrote: post #47
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

I'm hoping for something like this a few years down the line:

http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

Allowing Rust to generically adapt to an arbitrary Gc that it is nested inside of would be awesome.

Re: Four years with Rust

#53

Post by amelius »

kazagistar wrote: post #52
amelius wrote: post #47

Earlier quoted context omitted.

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

I'm hoping for something like this a few years down the line: http://manishearth.github.io/blog/2016/08/18/gc-support-in-r... Allowing Rust to generically adapt to an arbitrary Gc that it is nested inside of would be awesome.

Yes, that would be amazing.

Re: Four years with Rust

#54

Post by Manishearth »

steveklabnik wrote: post #22
Lev1a wrote: post #18

Earlier quoted context omitted.

There is also the possibility that a Rust 2.0 could fragment the community much like with Python2.7 Python3.x, which would be "undesirable" at best.

Yes, a split like this would be undesirable to say the least. Not to mention that systems people are used to near-total backwards compatibility; any sort of near-term timeframe for such a thing would destroy a lot of our credibility, in my personal opinion. I'm on team "never 2.0". We still have some desire to indicate "epochs" of Rust development, as undoubtedly, things like idioms will change over time, new librari…

I sort of want to make an RfC for 2.0 preparation. I am mostly on team "never 2.0", but I recognize that I am sadly not overlord of all things Rust (if I were we'd have stable emoji identifiers already) and it's quite possible that 2.0 will happen some day.

The idea is to come up with a set of processes for 2.0. If the community decides to do a breaking 2.0 for some reason, we should:

- Document exactly what has changed.

- Write extensive docs on upgrading

- Write good tools that do the upgrade for you when possible, and point out areas where they can't help with links to docs.

- Make it so that the cases where stuff isn't machine-upgradeable are minimal

- Be wary of actually removing deprecated APIs.

- Be wary of unnecessary extra breakage.

Python 3 took the attitude of "Okay, we're going to be breaking some things anyway, so let's break more!". I think that they had good reasons for doing that; and it makes sense in a way. But we may not want to follow the same philosophy.

Re: Four years with Rust

#55

Post by belovedeagle »

namelezz wrote: post #30

I would appreciate if anyone can share your dev setup for Rust. I tried Rust and Racer long time ago and it's not a pleasant experience.

A single tmux window, with vim on the left (with no special IDE plugins). On the right, autocall.zsh watches ./src and runs 'cargo build' whenever a file changes. (More specifically, I autocall running in a small pane up top and have it run cargo build piped through less [but you need to fake this as a tty to get cargo to output colors] in a specific, larger pane on the bottom.

Re: Four years with Rust

#56

Post by masklinn »

amelius wrote: post #47
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

> But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references).

Then again so does manual memory management if you're freeing a large object graph at once.

> At least a carefully written garbage collector can free objects incrementally, and concurrently.

You could get that with refcounting, stashing Rc0 objects in a list of items to free incrementally rather than freeing it all at once and synchronously.

Re: Four years with Rust

#57

Post by stusmall »

isuraed wrote: post #20
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

What kind of application s would Rust be an appropriate for? What languages is it largely meant to replace/improve on.

Here at ThreatX[1] we use it as a replacement for C. We've used it to write our web application firewall sensor and a real time threat analytics engine. Compared to C it has enabled us develop features rapidly and safely without sacrificing any performance.

1. https://threat-x.com/

Re: Four years with Rust

#58

Post by dbaupp »

Animats wrote: post #41

Rust as a language is now realizing the benefits of borrow checking. As the article points out, the syntax doesn't have to distinguish between move and assign. The borrow checker will catch a reuse of something already moved away. This turns out to be effective enough in practice that the syntax distinction isn't necessary. That wasn't obvious up front. Not having exceptions tends to generate workarounds which are ug…

> Rust as a language is now realizing the benefits of borrow checking. As the article points out, the syntax doesn't have to distinguish between move and assign. The borrow checker will catch a reuse of something already moved away. This turns out to be effective enough in practice that the syntax distinction isn't necessary. That wasn't obvious up front.

Could you say a bit more about what you mean by "now"? You write like it's a recent realisation but (as linked in the parent article) it was "discovered"/described/promoted more than 4 years ago: http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... .

---

Are your other two paragraphs related to the article, or are they just your general observations about Rust?

Re: Four years with Rust

#59

Post by ketralnis »

amelius wrote: post #47
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

> So memory management in Rust is certainly not a solved problem.

This looks like nay-saying just for the sake of it, but in case you're actually just confused:

Rust isn't reference counted unless you yourself add reference counting. Rust tracks ownership in the compiler so it knows statically, at compile time, when an object needs to be freed, and the compiler emits the code to do the freeing in that spot. Rc is a utility function: you can choose to opt into reference counting on a per object basis. But if you're not actually typing Rc yourself then it's not happening. Rust is no more reference counted than the ability to build the same thing in C makes C a reference counted language.

Re: Four years with Rust

#60

Post by echelon »

Manishearth wrote: post #44
mr_luc wrote: post #4

For those of us who are getting to the party 3 years late, thank you. Just my 2p for others learning: for me, Rc::RefCell was what I was missing, even after I thought I was up to speed. I was fine using Channels for inter-thread communication and I never needed Arc, but use of Rc is common in the Rust ecosystem and a lot of my early fights with the borrow checker weren't fights I needed to have. In situations where i…

> Rc is common in the Rust ecosystem I'm really surprised you think that's the case. Most rust codebases I've worked with use Rc very sparingly, if at all. If a codebase does use Rc there's usually one central thing that is Rc'd, with everything else using regular memory management. I have noticed that beginners coming from GCd languages often tend to structure their code in such a way that paints them into a corner…

> I'm not really sure how to teach idiomatic Rust though.

Learners should read and write lots of Rust. That's a great way to learn what is idiomatic. There will be early missteps, but thankfully the language makes it more comfortable when you do things the right way.

Post reply on HN