41–50 of 197 posts
Earlier quoted context omitted.
Rust has the exact same semantics there. Drop is useful when you need to explicitly notate that a value should end its life early.
It used to, they got subtler. See https://stackoverflow.com/questions/50251487/what-are-non-le...
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?
One cool thing about Drop (and some other cool stuff, like MaybeUninit) is that it makes doing things like allocating/freeing in place just like any other Rust code. There may be some unsafe involved, but the syntax is consistent. Whereas in C++ seeing placement new and manually called destructors can raise eyebrows.
Earlier quoted context omitted.
No, it would not free it. It takes a reference to the pointer and does nothing.
unique_ptr disposes of the object its holding when it goes out of scope unless passed to another unique_ptr or ownership is explicitly released. Presumably klipt would std::move the unique_ptr, hence the universal reference (which seems unnecessary, just pass it by value). Am I missing something? Does it not work with std::move?
For me, rust is still love & hate, even after 1 year of half-time (most of the free time I have) hacking. 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…
Zero cost refers to runtime cost, not compilation cost. Zero cost abstraction is not bullshit.
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?
Less common complaints are that it's missing: object oriented features like inheritance, a configurable gc (as java has), the ability to work with OS threads, c-compatible stacks for fast c-interop, ownership semantics, type-inference for arguments (e.g. as haskell does), operator overloading, dependent types, etc.
The list of things in the first set can mostly be summed up as "go has a worse type-system than C++/rust/etc, something much closer to java 1 before generics, or c". Basically, the language is intentionally crippled because it intentionally ignores advances in type-theory that have been shown to allow expressing many things more safely.
For example, sum types and match statements make modifying code much safer. People will write switch/if-else-ladder code to do exactly the same sort of thing even without them, the code will just fail at runtime rather than compile-time when a new variant is added or one is not handled by accident.
> or making the language unacceptably crippled like Go Gotta say, I lost a lot of respect for the author at this point. It’s not like I don’t love Rust - quite the contrary - but if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Go has been one of my languages of choice for over half a decade now, and for good reason.
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 used to be at the end of the block, which caused all manner of annoyance. So they spent a lot of effort improving the borrow checker, and now it's 'after last use'. 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-…
NLL only affects values without destructors.
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 used to be at the end of the block, which caused all manner of annoyance. So they spent a lot of effort improving the borrow checker, and now it's 'after last use'. 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-…
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?
Lack of generics is a big part of the issue. But more generally the focus on "simple" code means that more sophisticated abstractions are actively eschewed, and personally I find this makes writing Go code quite frustrating.