I benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago and my findings match what this post is talking about.

https://github.com/philippta/postgresql-cockroachdb-benchmar...

I recently learned that Odin has fully-featured text editing primitives in its core library. Coupled with the bundled raylib library, it should be fairly easy to build a GUI text editor from scratch.

https://pkg.odin-lang.org/core/text/edit/

I think TVs are just used as a residential proxies. No remote controlled chrome is running there.

Having watched both, they cover completey different topics.

You could have picked a better example, sorting algorithms are typically drop-in replacements.

The most shocking thing to me about the entire GitHub fiasco is: No matter how bad the uptime is, no matter how bad the UI is. We will keep using the software / service we depend on.

Why do we as software engineers have set fault tolerance and high availability as the primary goal of any software / infrastructure architecture? This shows it's completely irrelevant.

It is not. I am just not happy with the alternatives; Gitlab, and Codeberg, for well-discussed reasons. I will pounce as soon as the right one comes along, and I have a few on my radar.

Personally, Fastcomments and all my projects can easily be switched to a self hosted provider, keeping GitHub as a read only mirror. It's probably a couple days work with today's tools.

What? No. The people that stay are the ones that don't care, that doesn't mean no one cares. That's a selection effect.

The people that care left months or years ago. I'm one of them. It was really easy, Github doesn't offer anything special.

Try and run a Pagerduty with the same level of attention to detail as Github. Far fewer people use Pagerduty casually. That Github has casual users and lazy users does not mean fault tolerance and high availability are 'completely irrelevant'.

That might apply to personal users. But to businesses the switching cost is just too high. We had a discussion about it on our team. It was decided to keep using GitHub unfortunately.

Not all businesses have the same requirements. My company jumped ship months ago. We didn't consider switching to have significant cost, we did consider staying to have noticeable opportunity cost. Easy decision.

> There are surely cases where having an interface as an abstraction and multiple implementations makes sense.

I think most people aren't aware of the alternative, which is: A function that can call different implementations based on some other variable.

E.g. instead of having RealDB and MockDB type have a createUser() (method), you have a createUser() (function) that switches part of it's logic based on what DB is selected.

That's the prodecural way of achieving the same thing without needing a concept for virtual functions.

Casey explains this in the long discussion with Uncle Bob.

Yes, but there's not a chance that there's a material difference in performance between those options because of virtual functions.

Unless you're doing something really stupid, nothing other than the DB access is going to be worth optimizing. If those two options are accessing the DB in exactly the same way, then they will probably be within 1% of each other in performance.

Depends, for example if the variable that selects between the two implementations is a compile time constant (#define or constexpr variable) the compiler can really remove the conditional and all the code of the choice that is not always selected leading to higher performance and smaller footprint.

It doesn’t matter. You’re saving nanoseconds when a db access costs milliseconds. Better to focus on making the code easy to understand and change and focus your effort on optimizing the database.

you are hyperfocusing on a single example. there are contexts where it matters and others where it doesnt sure, but i dont think either approach is inherently easier to understand or maintain

The only context where the overhead of a virtual function call matters is in tight inner loops.

That's by far the easiest place to apply the "write something simple and readable and then measure and see if you need to change it" approach, so it just plainly doesn't work as argument against that approach.

Are you suggesting something like this?

    def createUesr(db):
        if db is type1:
            behaviour1
        if db is type2:
            behaviour2

See Casey's code snippets here: https://github.com/unclebob/cmuratori-discussion/blob/main/c...

Even in memory safe Rust, out-of-bounds array access also results in crashes.

The whole point of memory safety is that bugs can not be exploited. A memory safe program does not mean a crash safe program.

To me this looks like a cool demo product. Yet, the problem it's solving could be equally solved by a well integrated all-in-one business suite.

I don't run a small business myself, but I assume the scope of administrative tasks in such company is well defined and understood.

Not my app. Saw it online and found it funny. I'm #27