Yeah it doesn't win in every category. I will say watching it in the discord I saw its performance vary widely so the context and sys prompt plays a huge role. Initially it did great and solved some pretty heavy logic questions but after the context was loaded with trolling it degraded quite a bit and couldn't solve problems it previously was able to.
I was just talking with a Temporal solutions engineer this week and this metric is their recommended one for autoscaling on. Instead of autoscaling on queue depth, you scale on queue latency! Specifically for them they split up the time from enqueue to start, and then the time from start to done, and you scale on the former, not the total ("ScheduleToStart" in their terms).
Time from enqueue to start isn't a good metric - it completely disregards the queue size. Enqueuing 1M jobs won't change this metric as it only updates once the job reaches the front of the queue, and when the 1Mth job does that the situation is already over.
I had much better results with a metric that shows estimated queue time for jobs that are getting enqueued right now (queue_size * running_avg_job_processing_time / parallelism).
>>> I was just talking with a Temporal solutions engineer
Aha! Just as the second season of Loki dropped. Makes sense now
Less sarcastically - this ties in with the article i guess. runat time is the enqueue, and then you are arguing for two latencies - time enqueue to start and start to complete.
Its interesting to see how the Rails world still thinks in terms of the number of processes listening to a queue, instead of thinking in the cloud-native, elastic, serverless terms.
There's always an autoscaling delay, but Rails itself (and the community) don't seem to fit into the serverless paradigm well such that these questions around how to design your queues come up.
I think a lot of Lambda developers or Cloud Run developers would instead say "well my max instances is set to 500, I am pretty sure I'm going to break something else before I hit that", you know? Especially when using the cloud's nice integrations between their queues and their event-driven serverless products its super easy to get exactly as much compute as you need to keep your latency really low.
Yeah when your Rails monolith's image is several GiBs, uses roughly the same amount of memory, and takes almost a minute to cold start, autoscaling has a lot of inertia and gets pretty expensive.
Dang this is cool! I get why replit went so heavy on nix but I also feel like it must have a cost for them — nix is hard to learn, especially for folks new to development which I know makes up a lot of replits customer base.
We built a solution to the same problem with a similar approach[1], but that just snapshots any old files instead of doing nix derivations. Nix couples the build process to the content-addressability of the output, which works great if you want to put all the effort in to deterministic builds. We just read files like git does which works great for non-deterministic processes like npm install (tragically).
I like the idea of the Big Disk style of attaching a content addressable cache, but in our experiments we still found the network latency to the attached disk too high when reading file by file, like when booting a node app, so we’re caching a much smaller amount on a local SSD for each prod server. Maybe replit isn’t as sensitive to read perf from the cache layer, or they have fancy local per-node read through caching within the overlay setup? Regardless, cool!!
It’s a fundamental issue though — there’s no “figuring it out” that a government can do that won’t either censor or facilitate. 25 years has been long enough to find tactical policy changes that make it easier, but there aren’t any, which is why nothing has happened. The choice we have to make is either de-shrine free speech above all else or entrench hatred, and it’s bogus that we haven’t picked the thing that doesn’t kill people yet.
Practical dichotomy — that’s why this thread exists. You either platform it or you don’t, and you’re either legislated to do so or not. What middle ground do you see that allows this degree of free speech without platforming hate?
> either platform it or you don’t, and you’re either legislated to do so or not. What middle ground do you see that allows this degree of free speech without platforming hate?
Nobody has been legislated to do anything here. Cloudflare is dumping Kiwifarms. There are other hosts. That's one middle ground: a diversity of opinions on what constitutes unacceptable speech. Here's another: the government has no right shutting down Kiwifarms in the absence of a true threat [1], but Cloudflare is free to.
If you look at the history of communication technologies, particularly public ones (e.g. the printing press and television), this pattern recapitulates. An idealistic explosion of creativity. Weaponisation. Scrambling alongside states over-reacting. Then a middle ground.
We don't have anything close to consensus on the Internet, save perhaps for X-rated content. So private actors are figuring things out. We'll probably see a government response carving out protections for both speech and platforms, though hopefully nothing as onerous as what was done with TV [2]. And then over decades an equilibrium will arise. An equilibrium between "de-shrining free speech" and "entrench[ing]hatred."
The middle ground that already exists - the right of free speech doesn't guarantee an audience, and the right to assembly doesn't guarantee a platform. Censorship is permitted within the marketplace of ideas as an inevitable consequence of the fact that coerced speech cannot be considered free, but the government is far more limited.
If Kiwifarms wants to continue "this degree of free speech" it's up to them to find someone willing to tolerate their bullshit, and then to not step over the line, as they apparently just did with Cloudflare.
It's odd how situational people are about when free speech requires someone to be given a platform and when it doesn't. There's an almost impressive 180 on free speech rolled up in this philosophy, and it's a philosophy that I'm unfortunately seeing online more and more nowadays.
The idea is that the government has the power to censor private institutions and public schools as it sees fit, but private companies have no right to censor or exercise their own freedom of association. Actively harassing people online is free speech that people should just ignore, but trans people merely existing publicly and openly in public spaces is dangerous propaganda that the government needs to put a stop to -- merely being open about their own existence is crossing the line. It's a philosophy that's happy to censor identity, and loathe to censor actions. It's a philosophy that sees government involvement in speech as fine, and private/social involvement in speech as an existential threat to the 1st Amendment.
Free speech is used as the justification for these policies and arguments, but it's only a justification. The actual goal is the reinforcement of existing social norms and hierarchies, and free speech is applied situationally in order to further that goal.
In general, be suspicious of anyone who claims to be a free speech advocate who has this kind of backwards view of the 1st Amendment. The point of the 1st Amendment isn't to make it easier for the government to censor, and it isn't to make it harder for private institutions to moderate their own spaces. That's not to say that we can't talk about the free speech implications of moderation decisions -- but if you're excusing government censorship while criticizing companies, I immediately get real suspicious.
> The choice we have to make is either de-shrine free speech above all else or entrench hatred, and it’s bogus that we haven’t picked the thing that doesn’t kill people yet.
Most of us never enshrined free speech above all else. It was never controversial that free speech had limits, that sites had the right to moderate content and ban accounts, or that businesses could refuse service to anyone. Prior to 2016, something like this would not have even been newsworthy.
Painting this issue as black and white is just wrong. Both sides have immense ramifications for the world. Accountability for censoring bodies and people on these platforms is not easily solved.
A new paradigm for building web apps: a framework integrated with a runtime integrated with an IDE! https://gadget.dev
We think that so much of software development is still the same stuff repeated over and over: auth, hosting, CRUD, search, tables, forms, etc etc. Each app always has some juicy special something about it, but that core is wrapped in layers of stuff you don’t need to redo every time. Our mission is to make the first and only lines of code you write super pertinent to the specific problem you’re solving.
We’re starting with Shopify apps cause we can give developers a one click, fully managed, code-extensible API integration which is a lot of work with the Shopify API otherwise. Would love to know what y’all think!
Postgres materialized views have to be manually refreshed on a schedule, and so are always out of date, whereas ReadySet keeps your results up to date automatically as the input changes. For PG materialized views, the compute required proportional to the size of the input data, and is paid every time, whereas with ReadySet the computation is incremental, so it's proportional to the size of the change in the data over time.
And finally, ReadySet's (Noria's) big innovation is that the result set can be only partial, storing only the elements of the result set (and underlying data flow graph) that are frequently accessed, instead of the whole result set like a materialized view would.
This system doesn’t support interactive transactions does it? In that the whole read / write set needs to be known up front before a transaction can start being processed? I know that systems like FoundationDB and Calvin/Fauna work similarly and get incredible performance because sequencing is so much easier / lock free. I think those two systems couldn’t be adapted for interactive transactions really (without client side retries) but maybe warp could be which is cool!
Last I checked, the entire transaction is built in memory (and famously has a five-second time limit), so while you can make multiple round trips, it's not quite as useful as with other databases.
Boo!