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...
The Road to Rust 1.0
221–230 of 248 posts
Re: The Road to Rust 1.0
#222Earlier 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…
Re: The Road to Rust 1.0
#223Earlier 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.
Re: The Road to Rust 1.0
#224Earlier 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.
Re: The Road to Rust 1.0
#225Re: The Road to Rust 1.0
#226Wait, 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
#227When 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.
Re: The Road to Rust 1.0
#228Earlier 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…
Re: The Road to Rust 1.0
#229Earlier 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.
Re: The Road to Rust 1.0
#230When 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.