Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favorite Rust function

blog.jabid.in

Post reply on HN
Print view View original

51–60 of 197 posts

Re: My favorite Rust function

#51

Post by jchw »

viraptor wrote: post #47
jchw wrote: post #22

> 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.

It may be an unnecessary dig, but the author may indeed be familiar with Go and still think it's unacceptably crippled for all their use cases. The whole post is just their opinion.

Sure, and my opinion is that this is a very shallow takeaway. My whole comment is just my opinion.

Re: My favorite Rust function

#52

Post by kam »

cztomsik wrote: post #39

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…

> you can't initialize some const x: SomeStruct with a function call.

You can if it's a `const fn`. The set of features you can use in `const` is small but growing.

Re: My favorite Rust function

#53

Post by edflsafoiewq »

klipt wrote: post #13
wwright wrote: post #9

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.

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.

The equivalent to drop in C++ would be

    template 
    void drop(T&) = delete; // force callers to move

    template 
    void drop(T&& x) {
        T drop_me(std::move(x));
    }
edit: fixed.

Re: My favorite Rust function

#54

Post by oconnor663 »

Rusky wrote: post #48
Filligree wrote: post #32

Earlier quoted context omitted.

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-…

This is incorrect. Values still go out of scope and have their destructors run at the same time. NLL only affects values without destructors.

I think `#[may_dangle]` is an exception to this, and the standard library puts it on many (most?) container types.

Re: My favorite Rust function

#55

Post by hu3 »

gautamcgoel wrote: post #17

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?

Interesting how developer views can differ.

Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language.

https://news.ycombinator.com/item?id=21226347

Re: My favorite Rust function

#56

Post by dkersten »

Rusky wrote: post #44
dkersten wrote: post #38

Earlier quoted context omitted.

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?

Yes, you're missing that the type `T&&` is a reference, not a value, and so does not run the object's destructor when it goes out of scope.

Sorry, I edited right after hitting reply to clarify that I'm assuming the intention was to std::move the unique_ptr in, since it was T&& and not T&. Would that still not work?

Re: My favorite Rust function

#57

Post by The_rationalist »

cztomsik wrote: post #39

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…

Another PITA is the lack of safe static variables.

Re: My favorite Rust function

#59

Post by Rusky »

oconnor663 wrote: post #54
Rusky wrote: post #48

Earlier quoted context omitted.

This is incorrect. Values still go out of scope and have their destructors run at the same time. NLL only affects values without destructors.

I think `#[may_dangle]` is an exception to this, and the standard library puts it on many (most?) container types.

It is not an exception; #[may_dangle] does not change the time drop runs. All it does is promise that drop will not access borrowed data, allowing that data to die before drop: https://doc.rust-lang.org/nightly/nomicon/dropck.html

Re: My favorite Rust function

#60

Post by Rusky »

dkersten wrote: post #56
Rusky wrote: post #44

Earlier quoted context omitted.

Yes, you're missing that the type `T&&` is a reference, not a value, and so does not run the object's destructor when it goes out of scope.

Sorry, I edited right after hitting reply to clarify that I'm assuming the intention was to std::move the unique_ptr in, since it was T&& and not T&. Would that still not work?

It would still not work. All std::move does is cast to T&&, enabling overload resolution to pick a function with T&& as its parameter type.
Post reply on HN