TWiR quote of the week

From Why raw pointer doesn't own type parameter T for dropcheck. Hilariously accurate.

4 Likes

A question #rustlang devs. What is the difference between String and &str?

Tim McNamara on twitter

one is for touching and one is for looking

Alexander Payne on twitter

7 Likes

protip: the rust extern keyword has a --help flag

image

source on Twitter

17 Likes

We can solve this with more violence threads

A problem we can solve with even more violence even more mutexes

From Request coalescing in async Rust - fasterthanli.me

2 Likes

Macros, right. Macros are cool, but like... Macros are great, in the hands of users, for letting users extend the language without having to actually go through and pester the devs and get a thing upstream. They let you extend the language in your own way in very small ways. But my opinion is that a widely used macro is kinda like a bug report against your language. ... You control the language, this is your language, just make it so I don't need this.

-- What's New in Rust 1.58 and 1.59 :: Rustacean Station (timestamp: ~6:00)

2 Likes

I don't like that quote. Isn't it supposed to be exactly the other way around? Macros exist so that the language doesn't have to be perpetually modified and bloated with every last thing people want. People will want different things because they come from all sorts of different backgrounds, and even when they want the same thing, there is going to be disagreement about implementation details, surface syntax, etc. Macros make that problem go away trivially.

"Just make it so I don't need this" is a daft thing to say, because doing things properly and generally enough so that it ends up being a useful and coherent part of the language is hard, but at the very least, it's a very slow and bureaucratic process. Why that would be preferable over just writing my own macro in the way I like, without inflating the language and imposing my own style upon everyone else in a way that ultimately nobody is really pleased, escapes me.

Considering specifically that the host is talking about format string "literals", and that there seems to be a consensus even amongst IRLO folks that fully-general string interpolation with embedding of arbitrary expressions is a Bad Thing™, this opinion sounds really unfounded to me. It's especially weird how he says at 07:09:

I just think that there are some cases where we can think about more regular solutions to certain problems.

This sounds incoherent, because macros are certainly more regular than giving every problem its own language feature. They are a conceptually unified way of performing metaprogramming at the syntactic level, no matter what the resulting code happens to be doing. That's in sharp contrast with writing a specific compiler pass for format strings, then another one for thread locals, then a third one for lazy initialization, and a fourth one for quantum flux frobnication.

7 Likes

That's exactly what the quote says. Macros are a good thing for users to be able to extend the language. The quote is just saying that if the language itself is providing a macro, perhaps we should just extend the language.

In this case, the quote was about the idea of replacing println!("{x} {y}") with println(f"{x} {y}"). I'm not necessarily saying we want to do that, but it seems like a reasonable argument.

3 Likes

Another quote from the same fasterthanli.me article:

As the popular saying goes, there are only two hard problems in computer science: caching, off-by-one errors, and getting a Rust job that isn't cryptocurrency-related.

17 Likes

I don't like this quote much either.

Firstly is it really true that macros are intended as a means of extending the language? I have never seen them that way. I see macros as a way of generating lumps of code to some formula to perform some common task. Stamping out code that cannot achieved by regular fixed functions.

Secondly it seems to be a call to start extending the language itself with all kinds of features people are doing with macros. The println! vs println() thing being an example of calling for veridic functions. This chills me to the bone, if Rust starts bolting on everyone's pet language features willy-nilly it will go the same way as the C++ behemoth and become totally unfathomable.

Please don't let that happen.

4 Likes

Off-by-one error generally isn't a hard problem: most of the time there are between 2^n and 4^n ways to write the same program using different initial values and stop values for n counters.

Note that the off-by-one part is a joke; I wouldn't take it too seriously. See TwoHardThings for some attempts at sourcing.

7 Likes

From @blonk in Difficulty in inventing bugs.

11 Likes

This section can be skipped entirely if you know everything about computers.

From @Gankra in Rust's Unsafe Pointer Types Need An Overhaul - Faultlore

7 Likes

The nomination surprises me, as that article is full of like-minded arrogance, such as:

Unless you literally work on a C/C++ Standard Committee or are named Ralf Jung I will not be accepting your Umm Actually’s on these definitions and terms.)

8 Likes

Here's one that is quite enlightening. This is only part of the post and it's actually not the essence, but I'm not going to paste a huge Venn-diagram here. @Yandros' full post can be read here.

8 Likes

(from rust-lang Zulip)

8 Likes

!Send + Sync is "it's a long story".

@alice in A better term than "Thread safe"? - #7 by alice

10 Likes

I think Rust's beauty is that it allows you to do anything, as long as it is not dangerous. So you can afford to get as close to the fire as possible, knowing that you won't accidentally step too far and burn yourself.

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

(In reply to my comment about how Rust's approach to message-passing is more "share memory, guarded by using message passing on the access token" thanks to the internal heap pointers in things like Vec<T>.)

8 Likes

"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan J. Perlis, Epigrams on Programming

11 Likes

I think this is the opposite: a language that does affect how you think about programming is a language that fails to be intuitive (that shows as a steep learning curve). This is a disadvantage of Rust, one that I accept because I know there is no other way.