> Some people have reported that, thanks to Rust’s checks, they are more willing to write code that’s a bit more dangerous than in the equivalent C (or C++)
I rewrote a C project in Rust some years ago, and in the Rust version I included many optimizations that I probably wouldn't have in C code, thanks to the ability to do them "fearlessly". The end result was so much more performant I had to double check I didn't leave something out!
I've had no trouble hitting the Firebase API at the speed items are created, with a 5 second delay between retries.
For scraping HN directly, in my experience you have to go extremely slow, like 1 minute between fetching items. And if you get blocked, it may be better to wait a long time (minutes) before trying again rather than exponential backoff, in order to get out of the penalty box. You'll need a cache for sure.
Congrats on the project! You may be right. There are other SSE services, but I can't think of one that allows clients to subscribe without authentication.
Not requiring client auth certainly makes things simple. It can even work for private data if the topics are sufficiently unguessable.
> That physical button that takes 500ms to respond is still as dangerous.
My Volt's physical mute button seems to be software controlled. Normally it is very responsive, except when the car is starting up. It kills me whenever I start the car and the volume happened to be cranked up from earlier, music blasts, and the mute button is ineffective. Fortunately the volume knob seems to be hardware controlled and can be used to lower the volume when the car is starting. It's really unintuitive since both controls are physical.
The issues with WebSockets are more political than technical. WebSockets are the superior technical solution with wide availability. However, at present, HTTP has better tooling (e.g. debug tools, devops tools) and developers are more familiar with it. HTTP is the de-facto standard for APIs as well.
If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.
For building clustered backend services, messaging is great. And Django Channels looks awesome.
However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason.
I sometimes see webapps communicating entirely over WebSockets. I don't mean just the realtime push part, I mean everything, request/response traffic and all. I understand that HTTP is suboptimal in certain contexts, but let's not throw the baby out with the bathwater.
I rewrote a C project in Rust some years ago, and in the Rust version I included many optimizations that I probably wouldn't have in C code, thanks to the ability to do them "fearlessly". The end result was so much more performant I had to double check I didn't leave something out!