from Hacker News

My favorite Rust function

by jaseemabid on 10/12/19, 9:52 PM with 183 comments

by foopdoopfoop on 10/12/19, 11:42 PM
Reminds me of Coq's definition of `False`:
`Inductive False := .`
i.e., `False` has no constructors and hence is an empty type.
Anyway, this means that for any type `A`, you can construct a function of type `False -> A` because you just do this:
`fun (x : False) => match x with end.`
Since `False` has no constructors, a match statement on a value of type `False` has no cases to match on, and you're done. (Coq's type system requires a case for each constructor of the type of the thing being matched on.) This is why, if you assume something that is false, you can prove anything. :)
by unexaminedlife on 10/13/19, 1:07 AM
I get the feeling this doesn't really get into the meat of what "drop" is. It seems you can't really explain why you "love" a function without discussing its purpose. Maybe I'm wrong, I'm only really an outsider looking in when it comes to rust, but it does fascinate me as far as its goals. I would go so far as to say that it will be important for systems programmers to know in the not too distant future (if it's not already).
Isn't it really only there in case someone needs to "hook into" the drop functionality before the variable is dropped? Please correct me if I'm wrong.
EDIT: Minor editing to clarify meaning.
by holy_city on 10/13/19, 12:07 AM
I wouldn't say std::mem::drop acts like free at all, it's the equivalent of a destructor in C++. Mostly useful when you're dealing with manually allocated memory, FFI, implementing an RAII pattern, etc.
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.
by dbieber on 10/12/19, 11:36 PM
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.]
by grenoire on 10/12/19, 10:33 PM
Wow, elegant. This was probably conceived as an idea during the design phase of the language, it seems right.
by lpghatguy on 10/13/19, 2:29 AM
Sometimes Rust programmers write this same function as a closure, which can be known as the 'toilet closure'[1]:
```
    |_| ()
```
[1] https://twitter.com/myrrlyn/status/1156577337204465664
by hinkley on 10/12/19, 11:44 PM
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 represents a nontrivial amount of memory, and you don’t have fallback behavior that keeps the old data, then you might see something like
```
    drop(foo);
    foo = buildGiantBoject();
```
Most of the rest of the time it’s not worth the hassle.
by saagarjha on 10/12/19, 10:38 PM
There’s a number of fun C++ ones similar in spirit: std::move, for example.
by newacctjhro on 10/13/19, 1:54 AM
> Now this might seem like a hack, but it really is not. Most languages would either ask the programmers to explicitly call free() or implicitly call a magic runtime.deallocate() within a complex garbage collector.
The compiler actually implicitly adds drop glue to all dropped variables!
by cztomsik on 10/13/19, 12:05 AM
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.
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)

by millstone on 10/13/19, 1:09 AM

    let x = String::from("abc");
    std::mem::drop(&x);
    std::mem::drop(&x);
    std::mem::drop(&x);
    std::mem::drop(&x);

by flywithdolp on 10/13/19, 7:01 AM
can someone elaborate on this passage:
The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard.
i'm fairly ignorant on the various differences but my general feeling was that Go is quite useful?
by gautamcgoel on 10/12/19, 11:40 PM
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?
by jchw on 10/12/19, 11:43 PM
> 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.
by etxm on 10/12/19, 11:29 PM
> unacceptably crippled like Go
I just spit mezcal on a stranger.