TWiR quote of the week

[durka]

"With great power comes difficult to read extremely-generic signatures.", as they say.

-- /u/Lokathor @ https://www.reddit.com/r/rust/comments/igi6p0/prerfc_safer_transmutation/g2uevs3/?utm_source=reddit&utm_medium=web2x&context=3

[pickfire]

I wonder if quote of the week can be used to bust some myth.

But what's the point of a const function then?

It makes code like this compile:

const FOO: i32 = my_const_fn(13);

That code is rejected unless my_const_fn is a const fn .

That is the only effect const has on fn . And AFAIK we never say anything else anywhere in the docs, so I do not comprehend where all these extra assumptions come from that you have been making. I'd really like to know as I'd like to avoid people making such false assumptions.

I always thought that const means all of these happens in compile time and none of it goes to runtime except those called in non-const places.

Code in const "places" (usually called const contexts) must run at compiletime. So this statement is true but I don't think it means what you think it means. In particular, format is impossible to use in const contexts:

const FOO: String = format!("abc"); // does not compile

Since format! can only be used in non-const-contexts, that means it never happens at compiletime. Or rather, it is never guaranteed to happen at compiletime -- optimizations can do whatever they want, but there's no guarantee they ever happen.

-- @RalfJung github comments https://github.com/rust-lang/rust/pull/75894#discussion_r477192216

[RalfJung]

I like the idea, but it's there's not really a pointed quote in that comment I think.^^ Maybe except for this part.

But what's the point of a const function then?

It makes code like this compile:

const FOO: i32 = my_const_fn(13);

That code is rejected unless my_const_fn is a const fn .

That is the only effect const has on fn . There is no effect on optimizations or runtime code.

(Slightly edited as well.) But still that's rather long. And we're starting to artifically construct a quote rather than take a real one.^^

[zrk]

I don't know if it qualifies for quote of the week but I'm glad it was posted here so I could read it

[pickfire]

@zrk are you perhaps shocked by it like me and another member did, thinking that const can allow generating better code without side effects?

[Michael-F-Bryan]

In response to In this mesh class, what's wrong with my use of lifetimes? - #4 by trentj

@trentj

When the answer to your question contains the word "variance" you're probably going to have a bad time

Many hours of discussion with the borrow checker leads me to concur with @trentj here.

[dodomorandi]

@ZiCog

It's amazing how frequent such "rare edge cases" can be. Especially when there are millions of people using billions of files originating from God know what operating systems. Far better things are checked properly if one want robust code. As Rust uses do.

Disappointed with Path

[TomP]

Advice by @alice, relevant to every Rust nauplius who attemps self-referential structs. (emphasis added)
From How to resolve "error[E0499]: cannot borrow ... as mutable more than once at a time" in this case - #3 by alice

When you have a lifetime <'a> on a struct, that lifetime denotes references to values stored outside of the struct. If you try to store a reference that points inside the struct rather than outside, you will run into a compiler error when the compiler notices you lied to it.

[2e71828]

Slightly OT here, but should that compile error say something about self-referential structs?

[alice]

Figuring out the exact conditions is probably difficult, but I think it would be a good idea.

[TomP]

Data ownership design patterns? Feasible or not?

There's no magic to how we solved the memory management issues. clone() is your friend when conversing with the borrow checker. Don't put references in your structs. Don't share mutable data; use a channel to send changes to its owner. Don't worry about performance until you have a performance problem. You can probably infer the last one from the first three.

Sage advice for anyone programming in Rust: first get it working correctly, then measure, then tune performance only if necessary.

[jhpratt]

@josh

Sometimes you don't want the code to compile. The compiler's job is often to tell you that your code doesn't compile, rather than trying to find some meaning that allows compiling your code.

from IRLO

[aDotInTheVoid]

You want to be looking into languages that tell you not "programming is so easy with me" but "programming is actually fiendishly hard but I'm going to try my best to help you get through it in one piece."

Bodil Stokke on twitter

[jonstodle]

Rust has a curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will recoil at seeing Arc<RefCell<T>> , but won't bat an eye at using Python.

by ekuber

[Yandros]

@kornel

Rust's difficulty raises exponentially with layers of abstraction.

The whole post is worth reading, I'd say

• for those wanting to discuss about it / challenge that assertion, the quote of the tweek thread is not for that. Instead, take advantage of there being a dedicated thread for it.

[blonk]

Unfortunately it's from the survey, so I don't know who to attribute it to, but this made me chuckle:

[...] clippy is for people who find a certain emptiness inside when they finally get code through the compiler.

[aDotInTheVoid]

Just because Rust allows you to write super cool non-allocating zero-copy algorithms safely, doesn’t mean every algorithm you write should be super cool, zero-copy and non-allocating.

trentj on URLO

[josh]

And it's true that a lot of stuff requires a "sufficiently smart compiler" but really it's 2020, if your compiler isn't serving you breakfast in bed you need to be upping your expectations.

-- Jubilee on the Rust Zulip

[ssokolow]

Historically, C has been the best fit for these applications just because it so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing

-- Bryan Cantrill on what no_std is competing with

[mark-i-m]

Alternative title: mediocre C++ is arguably worse than mediocre rust.

I’d agree with that? I think the power and danger of C++ is that it assumes the programmer knows best. Rust assumes the programmer is wrong if it looks dangerous. So.. yes?

By sesuximo in https://news.ycombinator.com/item?id=24817594