231–240 of 248 posts
Earlier quoted context omitted.
AFAIK Rust is the only language that offers memory safety without garbage collection.
What about Ada?
Earlier quoted context omitted.
It's more systems-like. We don't pay any overhead for calling into C code, and M:N scheduling doesn't really provide advantages over 1:1 scheduling when you don't have a GC (and even when you do, the differences are fairly negligible on modern Linux).
With 1:1 scheduling, how do you limit stack size to something reasonable (a few kB per thread), which is necessary when you need to launch tens of thousands of threads?
Earlier quoted context omitted.
"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!
Earlier quoted context omitted.
Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) ->…
Overlong shifts are currently not handled correctly, yes, but they will not be undefined behaviour ; they will possibly be implementation-defined but will not lead to memory unsafety. > use-after-move [...] ---references outlasting their owner--- Not really, e.g. std::unique_ptr x(1); foo(std::move(x)); std::cout Unless you mean something other than `&` references. > Honestly, I loved the idea of Rust. I was sold a m…
In your unique_ptr example, you're right: the reference doesn't outlast its owner, but it becomes a dangerous zombie after getting its guts removed. It is worth mentioning that the behavior may or may not be UB depending on how `foo` takes its parameters: std::move is really just a cast.
Maybe interest is the wrong word to use; many functional languages have generated a lot of interest, but this interest has historically not translated into actual mass usage. Instead, popular languages have adopted certain functional features over time (lambdas, comprehensions, type classes, etc), but have remained fundamentally Algolian for the most part. Rust seems to go in the opposite direction: start with ML (or something ML-like, anyway), and strip it down until it fits into the C++ space.
I am definitely interested in C++ replacements, to be clear. I have explored things that stray from it much more than Rust, such as Haskell and ATS, but I went into those fully expecting to see something different. But look at documents such as [1], and tell me that it doesn't create the expectation that Rust is trying to fit C++'s shoes a little too tightly. Additionally, trawling through mailing list discussions, familiarity with C-like languages seems to have been a design principle since the start (see for example the vs [] for generics debate).
Finally, I wasn't (and am not) passing judgment on Rust for being what it is. I was conveying my experience from being excited about it, to being less excited about it after actually learning it. I don't expect a productive discussion to come out of it; I've also seen how defensive the Rust community can be [2].
[1] https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programm...
[2] https://pay.reddit.com/r/rust/comments/2bbeqe/it_started_out...
Earlier quoted context omitted.
I think one of the core challenges is how traits play with HKTs. You can only allow for the defining of HKed type parameters and type arguments so many ways, but it becomes more complicated when dealing with the resolution of traits around HKTs. In Haskell for ex. there is no `Self` so the type class can easily be dispatched on a higher kinded type without needing a receiver type. In Rust `Self` must currently be ful…
> I'm hoping to finish the RFC once all these features land and I can actually hack a prototype, instead of scribbling on paper. This would be amazing. One of the big issues blocking HKTs has been that though many folks want it there hasn't really been anyone willing to champion it yet. No pressure though - it is a tough problem.
Earlier quoted context omitted.
It's more systems-like. We don't pay any overhead for calling into C code, and M:N scheduling doesn't really provide advantages over 1:1 scheduling when you don't have a GC (and even when you do, the differences are fairly negligible on modern Linux).
With 1:1 scheduling, how do you limit stack size to something reasonable (a few kB per thread), which is necessary when you need to launch tens of thousands of threads?
Earlier quoted context omitted.
Overlong shifts are currently not handled correctly, yes, but they will not be undefined behaviour ; they will possibly be implementation-defined but will not lead to memory unsafety. > use-after-move [...] ---references outlasting their owner--- Not really, e.g. std::unique_ptr x(1); foo(std::move(x)); std::cout Unless you mean something other than `&` references. > Honestly, I loved the idea of Rust. I was sold a m…
My comment appears to have been more polarizing than I ever expected. Let me clear some things up. In your unique_ptr example, you're right: the reference doesn't outlast its owner, but it becomes a dangerous zombie after getting its guts removed. It is worth mentioning that the behavior may or may not be UB depending on how `foo` takes its parameters: std::move is really just a cast. Maybe interest is the wrong word…
On that note, would you interpret [a] as meaning Rust is trying to be a functional language? The reality is more plagiaristic: functional language have nice features and so Rust borrows some of them. (In my mind the correct interpretation of both documents would be: Rust is a mesh of various languages with enough similarity to many for translation guides to be helpful.)
There has been syntactic decisions tilting towards C++/Java/C# programmers (like the for generics), but as far as I can remember those sort of decisions are all minor in terms of semantics. For the most part the actual semantic behaviours are considered in terms of "does Rust need this" rather than "will this move us more towards C++" (even if the feature was inspired by C++).
[a]: http://science.raphael.poss.name/rust-for-functional-program...
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?
Lastly, Rust's type system actually allows 'this value must be kept local to a thread local' to be expressed, meaning there are two shared_ptr equivalents:
- Arc (Atomic Reference Counting), which uses atomic instructions like shared_ptr
- Rc, which uses non-atomic instructions, and so has much less overhead.
Rust also has move-by-default semantics, so there's no extraneous reference counting due to implicit copying. (Which is particularly bad with the atomic instructions of shared_ptr.)
Still sitting on the fence as to which language I should pick up on next - the only contenders are C++11 and Rust. How does Rust compare with C++11 as a language? C++11 seems to (in some ways) have caught up with what Rust has to offer (compared to older C++ versions) e.g. smart pointers, concurrency and regexes part of the standard library
I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can…
Earlier quoted context omitted.
My comment appears to have been more polarizing than I ever expected. Let me clear some things up. In your unique_ptr example, you're right: the reference doesn't outlast its owner, but it becomes a dangerous zombie after getting its guts removed. It is worth mentioning that the behavior may or may not be UB depending on how `foo` takes its parameters: std::move is really just a cast. Maybe interest is the wrong word…
I think the situation of your [1] is that Rust has ended up close enough to C++ that it's useful and meaningful to provide a translation guide between concepts, to help C++ programmers get up to speed more easily; it's certainly not a design document or anything like that. Maybe I'm missing your point. (As I said elsewhere, C++ has had a lot of experience in this space, and so has a lot of good ideas, Rust is not ash…
I must thank you for pointing that link out to me, though: it said what I was trying to say much better than I could in its prologue. Namely, how hard it is to sell a functional language to old-school C people, and how Rust may have a hard time with that (even if it's not a pure functional language).