jkarneges

You don't need django-channels anymore for SSE: https://docs.djangoproject.com/en/6.0/ref/request-response/#...

> 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.

The HN/Firebase API doesn't make this easy. For https://hnstream.com I ended up crawling items to find the article.

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.

It's a proof-of-concept for a potential startup idea, not endorsed by my employer. I simply picked tech in arms reach.

Maybe in 2028 this could be a real thing, regardless of where it is running. An edge cloud does seem ideal for national live events though.

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.

WAF could be nice though.

> Does Fastly support WebSockets yet?

It does! Can be served at the edge or passed through to origin.

> almost no one on their death bed wishes they had spent more time working / on their computer

And old age isn’t needed to figure this out. Even middle age will do. When I reflect on my life, I almost never think about past work.

(Yet, I remain mostly working.)

Does HN skew democratic? Maybe so. Still interesting to see the breakdown.

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.

He dropped out while I was developing this, so I removed him. But I could re-add him if it makes sense.

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.

Hi HN!

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.

There's also Pushpin, if you want the API to blend with your existing app.

Disclosure: Pushpin lead dev.

> rust async seems to be a terrible design blunder [...] that could destroy the community and render the language worthless

What an extreme take!

Async Rust as-it-is makes perfect sense for Rust's primary audience: folks who desire control/performance enough that they would otherwise be using C/C++. To call async an "efficiency hack" is to underestimate how important that efficiency is to Rust's existence. If async didn't work the way it does, it wouldn't have gained traction within the Rust community (folks would have just ignored it and kept writing state machines by hand) and it wouldn't have been able to act as a draw for C/C++ developers. It's a killer feature, and has enabled the language to thrive.

Not only is it a killer feature, the way it is designed is the only way it could have been. See: https://without.boats/blog/why-async-rust/

Thanks for the thoughtful reply. What you describe sounds awesome, and in fact some of these concepts are present in our stack but not fleshed out to this level, so maybe we could get there someday. The challenge is making it practical.

Currently, Fanout supports HTTP in addition to WebSockets. We consider the system to be generalized, in the sense that the user can build whatever they want on top of the available primitives, and we can always add more primitives. Most people are implementing "web" protocols (REST, SSE, GraphQL, etc), so what's available today gets us pretty far. You're right of course that we don't support arbitrary TCP protocols.

I suppose the reason we don't support bare TCP is Fanout is optimized for implementing pub/sub-style interfaces with minimal compute. In that context, it is preferable to work with coarse-grained input in order to avoid per-session processing. However, with Fastly Compute now in arms reach, I think we could embrace per-session processing, in which case implementing arbitrary TCP protocols could become practical.

Your idea of supplying custom L7 parsers to the routing layer is clever, and is not too far off from some things already on our mind. For example, our routing layer supports inspecting requests using custom rules supplied by the compute layer, though this is not yet exposed to Fastly users. Relatedly, the routing layer has an internal component that parses TCP streams into messages (by known protocol) and ships them over an IPC without caring about their content. So it's not too much of a jump to imagine how we could get to user-supplied L7 parsing.

> why is there no Lambda-like serverless compute substrate that allows your function to speak a connection-oriented protocol, by externalizing the connection-hold-open and per-connection book-keeping state into the routing layer, such that your own function in the system could scale-to-zero?

Fastly Fanout + Compute?

(disclosure: Fanout tech lead)

> 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.

Fastly has something like this: https://docs.fanout.io/docs/http-streaming

> Stop paying for €xpen$ive realtime

First time I've seen what appears to be a purely free project going on the offense against SaaS providers, complete with a mock pricing table. I wonder what the motivation is. Bad experience with a SaaS?

Brilliant website in any case. And I say this as someone who works on a realtime/push SaaS.

Fastly announced Fanout today, which is exactly this https://www.fastly.com/blog/unlocking-real-time-at-the-edge

Indeed, these kinds of abbreviated notifications are a great way to implement realtime updates. The code is simpler and there's less chance of screwing something up.

I've also seen this described as hints: https://blog.andyet.com/2014/09/23/send-hints-not-data/

Long ago, I used to develop on systems where my program was the only code running. For example DOS, or TI calculators. Hard rebooting or yanking out batteries was a regular part of the process. I’m not sure, but I wonder if Rust could have greatly reduced the frequency of those activities.