Well, maybe you’d better wait 10min instead of one, to make sure the led lightbulb heats enough, but still…

I tested this with a 5W IKEA LED light-bulb, since I was just doom scrolling, anyway:

• After 1 minute of being on, the bulb was still room temperature.
• After 10 minutes of being on, the bulb was lukewarm.
• After 10 minutes of being off, the bulb was room temperature, though the fitting maybe felt slightly warmer. That latter will probably depend on your installation, and how well it is able to disperse the heat.

This means that the solution either breaks down entirely, or is unreliable, since you are not (reliably) able to tell the first two buttons apart

Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:

'outer: while (...) {
    'inner: while (...) {
        if (...) {
            // this breaks out of the outer loop, not just the inner loop
            break 'outer;
        }
    }

    // some code here
}

In C/C++ you’d need to do something like

bool condition = false;
while (...) {
    while (...) {
        if (...) {
            condition = true;
            break;
        }
    }
    if (condition) {
        break;
    }

    // some code here
}

Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste

C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes

In practice, type inference in Rust is not a problem since the language is so strongly typed. In fact, it is more strongly typed than both C and C++, and will force you to cast values explicitly in cases where C and C++ will happily mess up your variables without warning. The absence of type inference would also be a major pain, since nested types such as iterators can get quite complex and very verbose. If you’ve programmed using older C++ standards, then you know this pain

I believe that it is useful in a few places. cppreference.com mentions templates as one case:

Trailing return type, useful if the return type depends on argument names, such as template<class T, class U> auto add(T t, U u) -> decltype(t + u); or is complicated, such as in auto fpif(int)->int(*)(int)

The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.

Additionally, the scope of the return type matches the function meaning that you can do

auto my_class::my_function() -> iterator { /* code */ }

instead of

my_class::iterator my_class::my_function() { /* code */ }

which is kinda nice

With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.

Honestly, the Rust way of doing things feels much more natural to me.

You can read it as

1. Define a function,
2. with the name getoffmylawn,
3. that takes a Lawn argument named lawn,
4. and returns a bool

Whereas the C function is read as

1. Do something with a bool? Could be a variable, could be a function, could be a forward declaration of a function,
2. whatever it is, it has the name getoffmylawn,
3. there’s a (, so all options are still on the table,
4. ok, that’ a function, since it takes a Lawn argument named lawn, that returns a bool

Amusingly, modern C++ allows you to copy the rust signature nearly 1:1:

auto getofmylawn(Lawn lawn) -> Option<Teenager> {
    return lawn.remove();
}

At this point the people complaining about Rust at every opportunity have become more annoying than the “rewrite it in Rust” people ever were