TWiR quote of the week

[ssokolow]

The amount of careful thought I've seen put into [Rust's] design – crafting async/await to work in no_std environments, or the new inline assembly syntax – has produced a language that is not only better than what I could have designed, it's better among axes I was not even aware existed prior to reading the Rust RFCs.
-- First impressions of Rust

[TomP]

This is not a commentary on the actual issue that triggered this response. Rather, I just liked the response.

@Yandros

If you don't want to use the tool that gives you compile-time properties, you will need to pay runtime cost

[josh]

Whoop whoop, this feels like being knighted, and all the work totally paid off. Iteration after iteration after iteration, and it really was just Rust pushing me into doing "what's right", which also happens to be fast as a freebie.

-- Sebastian Thiel in [performance] beating git in `git verify-pack` ✅ 🚀 · Issue #1 · Byron/gitoxide · GitHub

[ssokolow]

There is a more technical term for "wrong", too - maintaining invariants is maintaining "soundness". Code that breaks invariants is called "unsound".

-- Frustrated? It's not you, it's Rust

[alice]

You're smarter than Rust - and you may need to rethink your design a bit, so it's possible to tell the compiler about it.

And when you do, you'll discover mistakes you never knew you could make.

-- Reddit - Dive into anything

[aDotInTheVoid]

“macros are for when you run out of language”. If you still have language left—and Rust gives you a lot of language—use the language first.

-- https://twitter.com/pcwalton/status/1294676975575896064

[scottmcm]

Not only is our new Rust code simpler and cross-platform, but it’s faster to boot!

~ Why We’re Bringing Astropad Cross-Platform | Astropad

[juleskers]

Programming's always been frustrating. Rust just makes the frustrations more likely to happen to you, and not your users.

/u/legowerewolf pointedly summarizes Rust's guiding principles in Reddit Discussion "Frustrated? It's not you, it's Rust"

[Yandros]

Regarding alternatives to inheritance:

@trentj

Sometimes all you really need is an enum.

[pickfire]

Man, I love it when the #RIIR (“Rewrite It In Rust”) virus mania spreads like wildfire

rggr on lobste.rs gitoxide: pure rust implementation of git | Lobsters

[ssokolow]

Rust is a very different beast for me. It is a *much* bigger and *much* more capable language. However, I've found that it is, in many ways, a lot more restrictive in how you can approach problems. I frequently find myself being perplexed at how to eloquently solve a problem. When I discover the idiomatic way of doing it I'm usually both blown away by the brilliance of it and a bit disheartened by how difficult it would be to come up with that solution by myself :-).

-- /u/mikekchar @ Reddit - Dive into anything

[durka]

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

-- /u/Lokathor @ Reddit - Dive into anything

[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?