hdhrufjdi

Thanks for the additional info

Yes, they are: https://geizhals.de/raspberry-pi-4-modell-b-a2301761.html

75€ until the end of 2021.

Now 86€ as soon as there are new PIs available, note the 8gb model: https://www.berrybase.de/en/raspberry-pi-4-computer-modell-b...

New supply later this year: https://www.raspberrypi.com/news/supply-chain-update-its-goo...

> And it is bloody expensive, for 160 euro (4GB, PI 4), I can get much better x86 mini computer,

Which one? Is it at least as power efficient idling and on full load?

PS: PIs are usually a lot cheaper. You get 8gb for half the price usually. But it seems like you'd have to wait until later this year for such prices

Fwiw foldable bikes make storage and stairway usage way easier

Handle(command) runs in another loop at the same time, the scheduler.

I think we absolutely should care, because when the devices do something, the user still expects software to be fast. So if it is not fast enough, he buys a new device, because this is what he can do. He can't just buy the software rewritten. Usually

This is bad for sustainability

Growth never lasts. It is impossible

Interesting point.

I allow for panics when the panic is expected to never execute, i.e. logic errors.

I see how it can be problematic, and thought of adding a general logic error for such cases. However, it adds work for devs and the machine.

Still, panics can happen for allocations, where I don't know a solution.

Would you consider this as a problem as well?

If not, no_panic should suffice, right? Yeah, it might make things harder, but for rockets you probably won't use that many external crates and a bit more work should be acceptable, shouldn't it?

What would you like to see the devs and the lang team to do?

Unlimited except when it is too much is not unlimited.

Just set a limit then instead and don't market it as unlimited.

Bloat like?

Usually everyone knows what made it better to be in Rust, especially when it comes to C and C++.

Ever used Stackoverflow? They do yearly surveys. I am surprised there are people not aware of them

Joining a room from server perspective vs syncing the client to the rooms he has already joined

When was that the case? I can't remember tbh, and it would have been insane for rooms like Matrix HQ.

Maybe before 2020?

It's supported, e.g. mautrix-telegram uses it: https://github.com/mautrix/telegram/blob/master/ROADMAP.md

No idea what is your point.

The compiler is happy to compile without sanitizers enabled. Why should it require to implement a null check when deallocating when it doesn't when dereferencing?

Rust could avoid it through the Box abstraction that afaik assumes not having a nullptr

A bit of research revealed that you don't have to call into libc. You may use alternatives or even use sys calls directly, like Go apparently did: https://stackoverflow.com/questions/41720090/does-go-depend-...

PS: small overhead is technically still overhead; yet, I am not saying you should worry about it

The implications would be checking if it is null before performing the deallocation of the memory, which is a runtime overhead.

Stack overflow says "delete" would check for null before deallocation: https://stackoverflow.com/questions/4190703/is-it-safe-to-de...

Happy to be educated

Just a thought: null pointer check before deallocation

> Rust is easy to learn. For seasoned C++ programmers, Rust is easy to learn. When they first start out, Rust learners usually spend most of their time making sense of ownership and lifetime. Even if they don't explicitly express these concepts in code, experienced C++ engineers always keep these two concepts in mind when programming in C++.

Finally somebody understands this.

And why would that be the case?

Take a look at their messaging service that they marketed for years as E2EE while it was closed source and uploaded the chat messages readable by Apple to the cloud

The only mobile browser with proper ad blocking

Think so too