Live data from Hacker News

The Road to Rust 1.0

blog.rust-lang.org

221–230 of 248 posts

Re: The Road to Rust 1.0

#221

Wait, they've got rid of unique pointers? When did that happen? They were there a couple of months ago. That was one of my favourite language features...

My understanding is that they're still there, just as part of the standard library rather than as a language feature.

Re: The Road to Rust 1.0

#222

Earlier quoted context omitted.

> There's no reason why a program written in Ruby can't do the same stack allocations, reduced memory fragmentation and predictable performance automatically - if the Ruby VM was better designed. Escape analysis falls down pretty regularly. No escape analysis I know of can dynamically infer the kinds of properties that Rust lets you state to the compiler (for example, returning structures on the heap that point to st…

Rust must statically prove lifetime of references to stack allocated variables does not exceed lifetime of the variables they point to at compile time, in order to be 100% memory safe. How is that different than just an advanced escape anlysis? Theoretically a VM could do much more, because it could do speculative escape analysis (I heard Azul guys were working on such experimental thing called escape detection) and…

For one thing, Rust can reject programs at compile time if it's not satisfied with its analysis. For Ruby to get that, you might have to restrict the language in a similar way.

Re: The Road to Rust 1.0

#223

Earlier quoted context omitted.

VM could do see all the functions and do whole-program analysis. Inlining is an orthogonal concept.

You could in theory, but that analysis would likely be really slow. In any case, without the type system and compiler to enforce the discipline the programmer is going to lose a lot of control and predictability.

Not necessarily. As you said, Rust encodes that information in type signatures. Exactly the same information can be used in a VM and it could do escape analysis one method at a time then.

Re: The Road to Rust 1.0

#224

Earlier quoted context omitted.

You could in theory, but that analysis would likely be really slow. In any case, without the type system and compiler to enforce the discipline the programmer is going to lose a lot of control and predictability.

Not necessarily. As you said, Rust encodes that information in type signatures. Exactly the same information can be used in a VM and it could do escape analysis one method at a time then.

That's true. Maybe it would work, but I wonder if anyone has attempted it before...

Re: The Road to Rust 1.0

#225
post #217
post #80

Earlier quoted context omitted.

AFAIK Rust is the only language that offers memory safety without garbage collection.

C++11's std::unique_ptr and std::shared_ptr are also nice features. Does Rust provide more guarantees?

[deleted]

Re: The Road to Rust 1.0

#226

Wait, they've got rid of unique pointers? When did that happen? They were there a couple of months ago. That was one of my favourite language features...

My understanding is that they're still there, just as part of the standard library rather than as a language feature.

That's correct. What used to be ~T is now Box. We say 'boxes' instead of 'unique pointers' now.

Re: The Road to Rust 1.0

#227

When I first looked at Rust, I recall being very confused about the distinctions between crate, package, module, and library. It seemed like an area which could use some simplification.

"Package" and "library" are two words that mean the same thing. They're more generic terms for "crate," which is Rust specific. "module"s are ways of splitting up your code inside a crate: one crate has many modules, and each module belongs to one crate.

Re: The Road to Rust 1.0

#228
post #199

Earlier quoted context omitted.

Is worth noting that you don't reach for reference counting by default in Rust: your reach for references, then boxes, THEN Arc. You can find documentation on these types here: http://doc.rust-lang.org/guide-pointers.html

Well, you wouldn't go for Arc (atomic RC) unless you need to share data across tasks (threads), within the same task you can use Rc. This is different from shared_ptr in C++ which is always atomic and LLVM has to try hard (in clang, no idea what GCC does) to eliminate some redundant ref-counts. Oh and since Rc is affine, you only ref-count when you call .clone() on it or you let it fall out of scope. Most of the time…

That's true, thanks.

Re: The Road to Rust 1.0

#229

Earlier quoted context omitted.

C# lacks the language features to make dealing with such coding style sane and the libraries use the "idiomatic" approach - if you're willing to put on a straitjacket and throw away the libraries then why bother with C# ? That's not saying that C# can't be made more efficient by avoiding allocation in performance critical sections, but overall it's going to perform worse than C++, both idiomatic and non idiomatic ver…

Java will have value types soon. Also, C++ does some heap allocations behind-the-scenes quite often (e.g. with vector or string) which are hard to get rid of and they are much more expensive than in JVM/CLR. So not always idiomatic C++ smashes JVM/CLR in performance. YMMV and typical differences are small enough to not matter for most of server-side software like web-apps, web-servers or databases.

[deleted]

Re: The Road to Rust 1.0

#230

When I first looked at Rust, I recall being very confused about the distinctions between crate, package, module, and library. It seemed like an area which could use some simplification.

"Package" and "library" are two words that mean the same thing. They're more generic terms for "crate," which is Rust specific. "module"s are ways of splitting up your code inside a crate: one crate has many modules, and each module belongs to one crate.

Thanks, Steve! Have not yet had a chance to go through the new guide, but looking forward to it!
Post reply on HN