31–40 of 197 posts
Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?
Probably lack of generics?
Do variables go out of scope after last use or when the function exits? I could see the former evolving into the language if it’s not already the default behavior. In which case there’s only one situation where I could see this useful, and that’s when you are building a large object to replace an old one. The semantics of foo = buildGiantBoject(); In most languages is that foo exists until reassigned. When the object…
It's not just a matter of memory use. References and mutable references form a sort of compile-time read-write mutex; you can't take a mutable reference without first dropping all other references. See https://stackoverflow.com/questions/50251487/what-are-non-le... for more.
Earlier quoted context omitted.
Probably lack of generics?
I wonder if the author would have a more positive impression of Go 2, which is planned to ship with generics...
Go shouldn't be Rust. We already have Rust. Though while I say that, I'd still hate to have to use Go.
Earlier quoted context omitted.
It depends: if add1 borrows the value then this code is fine. If add1 takes ownership of the parameter then no, this will not work.
What do you mean by "will not work"? Will it not compile? And how do we write that with add1 taking ownership vs. not?
fn add1(x: Vec) -> Vec { // Takes ownership
return x.iter().map(|&x| x + 1).collect::>();
}
fn add1_borrow(x: &Vec) -> Vec {
return x.iter().map(|&x| x + 1).collect::>();
}
let x = vec![1, 2, 3];
let y = add1(x);
let z = add1(x); // error[E0382]: use of moved value: `x`
let x = vec![1, 2, 3];
let y = add1_borrow(&x);
let z = add1_borrow(&x);
let x = vec![1, 2, 3];
let y = add1_borrow(&x);
let z = add1(x);
(Note, I chose Vec here because Vec does not implement Copy: if I used i32 it would just copy the value in the non-borrowing case, which would make the code fine as no ownership would be transferred.)
I haven't used rust, so can you explain this to me: If I do the rust equivalent of: def add1(x): return x + 1 x = 1 y = add1(x) z = add1(x) then will x have been deallocated by the first call to add1 and will the second call to add1 fail? [You can ignore the fact that I'm using numbers and substitute an object if that makes more sense in the context of allocating / deallocating memory in rust.]
Earlier quoted context omitted.
The standard C++ way to free resources is the character '}'
Rust has the exact same semantics there. Drop is useful when you need to explicitly notate that a value should end its life early.
I haven't used rust, so can you explain this to me: If I do the rust equivalent of: def add1(x): return x + 1 x = 1 y = add1(x) z = add1(x) then will x have been deallocated by the first call to add1 and will the second call to add1 fail? [You can ignore the fact that I'm using numbers and substitute an object if that makes more sense in the context of allocating / deallocating memory in rust.]
Interestingly, the type of `x` actually does matter here in Rust! For most types, yes, passing something by value into a function will cause the memory to be "moved", which means that reusing `x` will be a compiler error. That being said, you can also either pass a shared reference (i.e. `&x`), which will allow you to access the data in Rust (provided you don't move anything out from it or mutate it, which would caus…
Earlier quoted context omitted.
void drop(unique_ptr && x) {} Would do the same in C++ for values held by unique_ptr: take ownership of the pointer and then free it.
No, it would not free it. It takes a reference to the pointer and does nothing.
Am I missing something? Does it not work with std::move?
It's a wonderful language but there are still some PITAs. For example you can't initialize some const x: SomeStruct with a function call. Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages.
That said, I wouldn't rather use C/C++/Go/Reason/Ocaml/? - that is probably the love part.
BTW: I've recently stopped worrying about unsafe and it got a bit better.
So my message is probably: - keep your deps shallow, don't be afraid to implement something yourself - if you get pissed off, try again later (sometimes try it the rust way, sometimes just do it in an entirely different way)
Earlier quoted context omitted.
Interestingly, the type of `x` actually does matter here in Rust! For most types, yes, passing something by value into a function will cause the memory to be "moved", which means that reusing `x` will be a compiler error. That being said, you can also either pass a shared reference (i.e. `&x`), which will allow you to access the data in Rust (provided you don't move anything out from it or mutate it, which would caus…
How does this implicit Copy trait interact with the Drop function? Doesn't that mean that the implicit copy would be dropped rather than the actual value for those types?