> 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.
> the kids who grew up in those homes are writing things that take place there
This is kind of like how trench coats are associated with detectives, because they were regular clothing for anyone around the time of early detective films.
I agree it has some problems. For now, it is mostly a UX proof-of-concept and probably not how an official poll should be conducted.
> What problem is this envisioned as solving?
Its core mission is to legitimize all candidates on the ballot. This is something caucuses and ranked-choice voting can do, but since our general elections don't work this way, I wonder if the voting experience could be augmented from the private sector. (Of course, efforts to change how our actual elections work is still worthwhile and can be pursued in parallel).
Basically, if enough people (millions) were to use an app like this to meta-vote before committing to a single actual vote, we could simulate alternative voting processes without government involvement.
Hmm. Yes, using Fastly for that. Can you go to https://ileantoward.com/geotest and see if anything looks fishy? Notably country_code and region (region should have a state code if country is "US").
I'm not sure there'd be much benefit to using shielding with WebSockets, since the traffic wouldn't be cached/collapsed. You can still shield HTTP traffic on the same domain being used for WebSockets.
One of the goals with the non-binding vote aspect is to encourage people to fearlessly vote their first choice. They can always change it to something else at the last minute.
Then again, since this is only polling and not real voting, there's not much to lose anyway.
Sorry about that! To keep friction low and to avoid people voting in the wrong state on purpose there's no way to select your location. In a future iteration I want to relax this but not sure how yet.
Needs more participants. :) If there were thousands of votes I expect the percentages would align with traditional polling, although if they didn't that would be super interesting.
I made a presidential polling website with real-time electoral results. It requires semi-live participation and votes can be changed at any time. Only visitors from the USA can participate. Congressional district is determined by IP address.
The idea is to enable a coordinated voting process, where selections are non-binding and negotiable rather than blindly cast once. Kind of like a presidential caucus, but national and over the Internet.
The infra is Fastly & DigitalOcean. Backend is a Django service running on DO App Platform with Postgres. Fastly is used for edge logic, captcha, and pushing updates to the page (Fanout). In theory it should be able to handle millions of participants.
I operate a bit like this too, after I noticed a friend requiring a whole pot of coffee to get through the day. In the morning if I'm desiring coffee I ask myself for the justification. Bad sleep on a random weekday is not sufficient. My most preferable time to drink it is after a very good sleep during a focus time block. And of course, it remains potent. I've been drinking coffee for about 5 years now, and my "dose" is still very little: one small cup that I usually don't even finish, and I'm good for the day.
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!