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

91–100 of 199 posts

Re: Four years with Rust

#91

Post by steveklabnik »

elihu wrote: post #88
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…

> There's still too much that has to be done with unsafe code. But the unsafe situations are starting to form patterns. I think as long as those patterns can be abstracted out and moved into thoroughly-vetted libraries with a safe interface, unsafe code isn't really a problem. I expect that getting Rust's standard libraries to a place where regular applications very rarely need to create their own unsafe code blocks…

Is there something today that you're seeing that causes applications to use a lot of unsafe? In general, it should mostly be in library code, not application code.

Re: Four years with Rust

#92

Post by internetionals »

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…

Since refcounting only happens expicitly it should be pretty clear where possible drops happen that lead to large pauses.

It wouldn't be too hard to replace that Rc with an Rc that performs deferred drops by putting them in a queue and performing a number of drops at an oppurtune time (eg. using an idle-hook in a event loop).

It might even be possible to send all drops to a thread dedicated to dropping, but that would probably only work if the contents are Sync or Send. This form of async drops should always be possible for Arc.

But big pauses should rarely occur since refcounting is something that has to be added explicitly, Rust is a language where compound types are used extensively instead of building dynamic structures using collections for trivial things and the use of Drop trait is not something that can be fully relief upon (making that most solutions try to go without using it). This should make most drops pretty lightweight, even when dropping large numbers of items.

Re: Four years with Rust

#93

Post by CryZe »

Manishearth wrote: post #54
steveklabnik wrote: post #22

Earlier quoted context omitted.

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 chan…

I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).

Re: Four years with Rust

#94

Post by elihu »

steveklabnik wrote: post #91
elihu wrote: post #88

Earlier quoted context omitted.

> There's still too much that has to be done with unsafe code. But the unsafe situations are starting to form patterns. I think as long as those patterns can be abstracted out and moved into thoroughly-vetted libraries with a safe interface, unsafe code isn't really a problem. I expect that getting Rust's standard libraries to a place where regular applications very rarely need to create their own unsafe code blocks…

Is there something today that you're seeing that causes applications to use a lot of unsafe? In general, it should mostly be in library code, not application code.

No, but I'm pretty new to rust and haven't written enough code to know how often situations that call for unsafe code blocks come up.

(My current project I'm using to learn Rust is to port a ray-tracer I wrote in Haskell. I wouldn't expect functional-style code to require a lot of unsafe blocks and I haven't needed any yet, but who knows?)

Re: Four years with Rust

#95

Post by cesarb »

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).

That's still a predictable pause: it's the number of references contained within the array. If you know your array will hold at most ten references, it will take at most the time to free the ten references. Also, you know this will happen when the last reference is dropped - no earlier, no later. If your program can't handle the pause at that moment, you hold the reference until it can. If you know another component (perhaps in your own call stack) holds a reference, you know it won't be freed. And so on.

Re: Four years with Rust

#96

Post by steveklabnik »

elihu wrote: post #94
steveklabnik wrote: post #91

Earlier quoted context omitted.

Is there something today that you're seeing that causes applications to use a lot of unsafe? In general, it should mostly be in library code, not application code.

No, but I'm pretty new to rust and haven't written enough code to know how often situations that call for unsafe code blocks come up. (My current project I'm using to learn Rust is to port a ray-tracer I wrote in Haskell. I wouldn't expect functional-style code to require a lot of unsafe blocks and I haven't needed any yet, but who knows?)

Cool, just wondering. In general, unsafe code should be encapsulated, to isolate its possible effects, and once you've got it isolated, it's easy to break that bit out in a library.

Re: Four years with Rust

#97

Post by Animats »

pcwalton wrote: post #89
Animats wrote: post #79

Earlier quoted context omitted.

Never read "smallcultfollowing" before. The "implicitly copyable" problem is amusing. That was dealt with by Wirth in Modula 1 with the rule "if the programmer can't tell, it's up to the compiler". Thus, non-writable objects could be passed either by reference or by copy, depending on object size. This was up to the compiler. The usual rule was that anything up to 2 words in size was copied. Since the called function…

We tried making copy/move an optimization. The number of useless copies that ended up in the resulting code was absurd. You think compile times are bad now…

You mean there were lots of copies that made it to the back end, only to be converted to non-mutable references late in the compilation process?

Re: Four years with Rust

#98

Post by amelius »

cesarb wrote: post #95
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…

> 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). That's still a predictable pause: it's the number of references contained within the array. If you know your array will hold at most ten references, it will take at most the time to free the ten references. Also, you know this…

> If you know your array will hold at most ten references, it will take at most the time to free the ten references.

True. But if those references themselves contain references, it may become tricky to manage all of this. You basically don't want to think about it.

But, like others mentioned, you can put the objects in a queue, and free them in the background. It would be interesting to know how such a solution stacks up, performancewise, against an incremental, concurrent garbage collector.

Re: Four years with Rust

#99

Post by setori88 »

steveklabnik wrote: post #37
wyldfire wrote: post #28

Earlier quoted context omitted.

I hate to drag a thread like this out but I'm genuinely curious: why is there someone/are there people out there who have such an axe to grind? Or are they just trolls?

I wrote an extremely long comment here, but deleted it. I'd rather say this: like anyone who works in public, I am very open and vulnerable to criticism. When you work in public for a long time, there's a ton of reasons for people to decide that they hate you and have an axe to grind. Some of those things are things I still stand by, some of them are things that I agree that I was in the wrong. I am not a perfect per…

Steve you're a good chap doing some solid, respectable and valuable work. These things are just troglodytes looking to inflict pain. The interesting thing is, they could totally transform themselves by doing constructive work and presenting it to the community. It's then, quite possibly, they realize, it is your attention they seek.

Re: Four years with Rust

#100

Post by Manishearth »

CryZe wrote: post #93
Manishearth wrote: post #54

Earlier quoted context omitted.

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 chan…

I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).

That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.
Post reply on HN