Clippy catches it:
warning: taken reference of right operand
--> src/main.rs:14:5
|
14 | a() & & b();
| ^^^^^^-----
| |
| help: use the right value directly: `b()`
5 Likes
From this AMA :
I guess I would say that, it's not only important that it be possible to do a good design in a given language, but that the language actively encourage it by making the bad design painful. I think rust does a FANTASTIC job of this.
9 Likes
<m4b> i'm writing generic code so generic right now i don't know how its working, but it does
Referring to this code.
5 Likes
https://github.com/rust-lang/rust/pull/45501#issuecomment-340159627:
assumeis dark magic of the higher schools, so I'm not surprised there are sparks. I think it's best to not use it unless absolutely necessary.— @bluss
3 Likes
Is something wrong with me if that description actually made me want to look up this assume thing? 
1 Like
On #rust-internals wrt. https://github.com/rust-lang/rust/pull/45527
durka42 IMO the name "dangling" is scary enough
Havvy gives durka42 aptr::dangling::<Candy>().
durka42 declines tounwrap()it
6 Likes
A brilliant observation by @kickass_turing on reddit about Rust code being refactoring friendly:
Also the way I see it is that Rust makes problems local.
3 Likes
Another nice example of the "lisp effect", where learning one language makes you better in another 
5 Likes
I think x & & y is still, unfortunately, different from x && y.
See: Rust Playground (x & & y is really just x & y, which doesn't short-circuit boolean logic)
1 Like
I'd think & & should just flat-out be an "expected expression, found ..." error like it is with 1 + + 2.
x && y makes sense and x & &y is meaningful as "bitwise AND together x and the auto-deref-coerced value of y" , but x & & y looks like it's guaranteed to be a typo-induced bug.
Such arbitrary introduced whitespace sensitivity is the death of automatically generated code, though (think macros).
Point, but it should at least be a warning. (And that's assuming that rustc can't just handle macro-generated code differently in that case and force any re-serialization of the AST back to the spaceless form.)
When I look at 5 & & 5, I don't see 5 BitAnd Borrow(5). My intuition is to see it as some weird no-op pass-through special-case of (5 BitAnd) BitAnd 5 or 5 BitAnd (BitAnd 5).
Heck, until I actually looked into what x & & y was doing, I firmly believed that the compiler only parsed & as a borrow operator if there was no whitespace between it and what follows.
(ie. "&'s status as a unary operator is determined by whitespace" won out in my intuition despite my knowing that - as a unary operator is not whitespace sensitive in Rust. I believed that separating them was like writing ma tch { rather than match {)
Who knows how many other "at most, one semester of C and C++ combined back in the hazy days of university" programmers will make that mistake.
I know what you mean, but for me this is just too much guesswork on the compiler's part. As far as I know, whitespace between tokens does not matter anywhere in Rust right now. (Also, not all generated code comes from macros.)
It's not like making the mistake will get you a typechecking program that only misbehaves at runtime. In contrast to similar issues in dynamic languages, such as the "interesting" case a in b < c in Python.
[please insert kind reminder to move these discussions into a new thread]
Thank you very much ladybugs and gentlecats.
4 Likes
"Although rusting is generally a negative aspect of iron, a particular form of rusting, known as "stable rust," causes the object to have a thin coating of rust over the top, and if kept in low relative humidity, makes the "stable" layer protective to the iron below"
From: Rust - Wikipedia
17 Likes
I assumed someone made a recent change in Wikipedia in a jest.
So I tracked the change in Wikipedia, and it is more than a year old.
The WIkipedia diff.
3 Likes
No, that is a real thing. It is sometimes used to protect steel infostructure. Although it has gotten less common as it does not hold up as well in the wild as it does in the lab.
I do love how ambiguous that quote is. It can so easily be read as using rust as a metaphor for Rust.
3 Likes
<mbrubeck> I think that I shall never see
<mbrubeck> a poem as pretty as Result<Option<T>,E>
7 Likes
Every great language needs a Steve.
Someone from hackernews about @steveklabnik: https://news.ycombinator.com/item?id=15981227
By the way, let me tell a personal story of how I've actually got involved with Rust.... This happened shortly after 1.0. At that time, I've just finished the year-long C++ course for master's students at my university. The course instructor was really really great, and I've got a solid understanding about major moving parts of the language. I'd read "the C++ programming language" book before, and I'd even pushed some semi-production C++ code, but, after working with the course instructor, I came to realization that I hadn't knew a thing about C++ before! So, my conclusion was that everyone who wants to touch C++, should really attend a university and take a proper master's-level C++ course.
And then, Rust comes into my life. I open a nice minimalist webside, and I see a link to "The Rust Book" there. I click the link and I see the official book which just goes and teaches you how to use the language! So, I've read the book and I could program in Rust! (granted, I needed quite a lot of practice to stop fighting the borrow checker and to learn that you shouldn't put extern crate rand into each and every of your modules, but these are details )
The fact that there is an official book which you can just read and be able to use the language astonishes me even today!
Thanks a lot to all of you, who contributed to Rust documentation in any form, and especially to @steveklabnik! 
20 Likes
If C is like playing with knives and C++ is like juggling chainsaws then Rust is like parkour wearing protective gear while suspended from strings. It may look ridiculous at times, but you can do all sorts of awesome moves that would be damn scary or outright impossible without it.
17 Likes