lysdexic

As a rule of thumb, I would say that recursion should never be used in place of a for loop.

If you don't know what you're doing with a recursive function then you risk pushing stuff to your call stack proportionally to the number of items you want to iterate over.

If your collection and/or the size of the stuff you're pushing to the stack is large enough, your app will crash.

If you know enough to avoid growing the call stack then you know enough to not rely on third parties to figure out if you need an iteration of recursion.

I think you're succumbing to the belief that if a solution isn't perfect then it doesn't work. That's not how things work. You can have incremental improvements that replace a big problem with a smaller problem, and a smaller problem is easier to solve.

Also, StackOverflow already suffers from old and stale replies for years, and that's not hurting the site. Oddly enough, that's a problem that's mitigated with the way that data is queried,and that's handled quite well with large language models.

They’ve not been closed as duplicates or anything, just no answers.

This suggests your questions are a factor. Perhaps the topic is too niche? Perhaps the questions are too specialized?

Recently I gave SO a try with a tricky but low-hanging fruit question, and the problem I faced was the exact opposite of yours: I received too many comments and answers. The problem was that 99% of those replying were clearly clueless newbies and seemed to be piling on to try to farm reputation points. Some of them were even not reading the question at all, using a strawmen of sorts to dump the answer they had, and even presenting code snippets that were broken.

I don’t have an account there because of that reputation, and why would I now that I have access to chatgpt?

I think StackOverflow is rolling out a GPT-based service that generates answers to your questions based on SO's data.

You need to train ChatGPT to get it to output decent results. SO seems to be working to do that for you.

FTA:

A few months earlier, the engineering team at Amazon Prime Video posted a blog post explaining that, at least in the case of video monitoring, a monolithic architecture has produced superior performance than a microservices and serverless-led approach.

I recall reading a write-up of Amazon Prime's much talked about migration away from server less and into monoliths.

The key take is that Amazon Prime's problem is being wrongly pinned on microservices by the anti-microservices crowd. It was mainly an utter failure in analysis and architecture, where system designers failed to take into account basically the performance penalty of sending data over a network and followed a cargo cult mentality of expecting a cloud provider to magically scale out to buy back the throughput that their system design killed.

Of course when they sat down and actually thought things through, eliminating the need to shuffle data around over random networks ended up avoiding the penalty caused by sending data over a network.

The important thing is that they can pin the blame of a design failure in an architecture, and the anti-microservices crowd eats it up. Except that it says nothing about either microservices or even server less architectures.

Perhaps I'm being dense and coffee hasn't kicked in yet, but I fail to see where is this new computing paradigm that's mentioned in the title.

From their inception, computers have been used to plug in sensors, collect their values, and use them to compute stuff and things. For decades each and every single consumer-grade laptop has adaptive active cooling, which means spinning fans and throttling down CPUs when sensors report values over a threshold. One of the most basic aspects of programming is checking if a memory allocation was successful, and otherwise handle an out-of-memory scenario. Updating app states when network connections go up or down is also a very basic feature. Concepts like retries, jitter, exponential back off have become basic features provided by dedicated modules. From the start Docker provided support for health checks, which is basically am endpoint designed to be probed periodically. There are also canary tests to check if services are reachable and usable.

These exist for decades. This stuff has been done in production software since the 90s.

Where's the novelty?

Having said this, I'd say that OFFSET+LIMIT should never be used, not because of performance concerns, but because it is fundamentally broken.

If you have rows being posted frequently into a table and you try to go through them with OFFSET+LIMIT pagination, the output from a pagination will not correspond to the table's contents. Fo each row that is appended to the table, your next pagination will include a repeated element from the tail of the previous pagination request.

Things get even messier once you try to page back your history, as now both the tip and the tail of each page will be messed up.

Cursor+based navigation ensures these conflicts do not happen, and also has the nice trait of being easily cacheable.

For the article-impaired,

Using OFFSET+LIMIT for pagination forces a full table scan, which in large databases is expensive.

The alternative proposed is a cursor+based navigation, which is ID+LIMIT and requires ID to be an orderable type with monotonically increasing value.

You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.

The only time I had to brush up on data structures and algorithms is when I apply to job ads, and recruiters put up bullshit ladder-pulling trivia questions to pass to the next stage of a recruiting process. It's astonishing how the usefulness of a whole body of knowledge is to feed gatekeepers with trivia questions.

The decimal representation of real numbers isn’t unique, so this could tell me that “2 = 1.9999…” is odd.

I don't think your belief holds water. By definition an even number, once divided by 2, maps to an integer. In binary representations, this is equivalent to a right shift. You do not get a rounding error or decimal parts.

But this is nitpicking a tongue-in-cheek comment.

"Appendable” seems like a positive spin on the (...)

I don't think your take makes sense. It's a write-only data structure which supports incremental changes. By design it tracks state and versioning. You can squash it if you'd like but others might see value in it.

It’s usually easier imo to separate them into different processes (...)

I don't think your comment applies to the discussion. One of the thread pools mentioned is for IO-bound applications, which means things like sending HTTP requests.

Even if somehow you think it's a good idea to move this class of tasks to a separate process, you will still have a very specific thread pool that can easily overcommit because most tasks end up idling while waiting for data to arrive.

The main take is that there are at least two classes of background tasks that have very distinct requirements and usage patterns. It's important to handle both in separate thread pools which act differently. Some frameworks already do that for you out of the box. Nevertheless it's important to be mindful of how distinct their usage is.