ReflectedImage

Authoritarian states are a very ineffective model. A leader can lead their small band of merry man to rob the highway alright. But it doesn't scale up to larger groups of people.

If you talk to the CEOs of large companies or miltary leaders, you find that they are unable to exert effective control of their organisations. The organisation will do whatever it wants to do. The leader can make their command but at every level through the organisation that command will be slightly subverted. The more layers, the less of that command will get through.

Since it's in the news, take for example Putin and Russia, Putin thought he had tank battalions that his lower downs had sold for parts decades ago. Based on the information in front of him, he should have taken Ukraine in several days regardless of resistance by the locals.

And whilst you might think it's impressive that he cut the budget in US congress to Ukraine, back-handed deals to send old Soviet equipment from 3rd party countries to Ukraine were made and now they are exhausted London is loaning Ukraine, Russia's money.

Putin's authoritarian Russia might be able to cut off the head of democracy but he's up against a five headed hydra. Democracy is a lot more scary than Authoritarism from a military perspective.

"You do not want your food supply being run according to democratic principles, you want it to work."

This is something that people don't really get, what's important is that the people delivering the food get the sack if they failed to do it. As long as that happens it's okay.

That's the reason why socialist and overly authoritarian countries have supply problems, they don't have an effective mechanism to replace failing organisations. Venezuela isn't able to extract Oil because the Oil dereks are run by the local dictator's family members.

One of the main points of VMs is to subdivide servers.

But if we packing low power servers this densely we might not need to.

Can we ditch virtual machines if we are packing 672 servers per rack?

Generally speaking, more sophisticated designs perform worse both on time to implement and on code correctness.

That's just the way it usually shakes out.

DSLs are known in academic literature as 4th generation languages (whereas Go/C# would only be 3rd generation languages), they are really good thing as long as you aren't the person implementing them.

You can do that via much simpler message passing instead. No "thread-safe types", no "borrow checkers", no "verifying and upholding all the requirements manually". The downside is you are sacrificing performance.

Rust is for high performance, high concurrency applications where the developer can spend all day building them.

Software developers tend to be far more productive and write less bug filled code in "toy" languages. Progamming language complexity is usually just plain bad for developers at any skill level.

But Japan has a collapsing population due to said work ethic, which is a far more serious problem in the long run.

I think language simplicity is a blind spot for most developers. Programming languages shouldn't be judged just based on their performance (otherwise assembly language would be #1) but also how simple they are. The simpler the better.

Go is simpler than C# and that's giving it the advantage over C#.

Who would abuse a free service like that?

Datablock b6f3dff6:

5f3d4f384231fe2cdc2b68e593e1e239601d65828f61cc05

71efc6363a22e66ad757cb363d7f618c01bd74128452401d

6e68aa26d7f2e59553880157652d07df64e3583d51f5ba76

f9f7a0adcdaa7bc01b5b470bb5ab43f0fb506bcb8be85925

f34f81e228aa13ad20644be83590faad07acd9dadf353bc1

13bea4dc64ebcc1814c27fe51b28d48eddedad955a5df41e

Pretty much all work loads, work loads that are not affected would be the exception

Basically, he won't face charges because the whole thing is bs.

We can't do that as Python is the programming language that meets business needs the best and they pay the bills.

Ultimately, hosting a relational database on AWS will cost 10x as much regardless of which non-working flavour of it you choose.

Million dollar database bills do not happen outside of the cloud world.

In theory, Postgres will be 10x faster on bare metal than AWS. From practical experience that is also what I see.

It's the difference between using SSD and EBS for your disk storage.

This is very simple:

EBS has a latency of around 2 ms.

SSD has a latency of around of around 0.25 ms.

A relational database will have around 10x the performance on an SSD compared to EBS because relational databases need to ensure data has been fully written to disk.

Then you are shipping some incredibility buggy software then whether you are aware of that or not.

The overwhelming majority of bugs in software are behavioural bugs, which typing does not catch.

If you want to go down the formalism route to catch bugs then at the bare minimum you require Z formal specifications for all your code.

Do you have Z formal specifications for all your code?

It's only around 1% of errors, it's not very good.

PostgreSQL gives the performance if you are not running it on AWS

I would say "AWS unsuitable for real world business applications".

Every business application uses a database and AWS charges $3000 per month for the same database that could run on your MacBook, it's beyond ridicious.

Sounds right to me. Postgres on AWS doesn't work because relational databases don't work on networked storage.

Various academic studies on the topic

People get this weird idea in their heads that if they do more stuff than what they have done is better in some way. In practice however simpler code usually wins out.

Docstrings are usually a lot better than type hints for that purpose.

If you don't test the behavior of your code then it is wrong. Whether the code could in theory be compiled isn't a very good test case.

Static type checking has a measured bug catch rate of <1%. So the quality of any code where the programmer depends on static typing to verify correctness rather than unit tests is very very low.

Static type checking catches <1% of bugs. As a tool for verifying software correctness it's completely and totally in-effective.

The majority of bugs in code are about the behavior of the code rather than the typing. You require unit tests or some other more advanced technique.

Those are some nice blog articles but the general consensus is that on a per-line basis duck typed and statically typed code have the same amount of bugs.

The duck typed code is also significantly shorter, less lines of code per software feature means less bugs per released software feature.

It's very difficult to compete against just having less code. You only needed to write 1000 lines of code instead of 3000 lines of code? Then you just eliminated 66% of the bugs.

Static typing on the other hand catches less than 1% of bugs.

So you can go for the duck typing approach and remove 66% of the bugs in your code or the static typing approach and remove 1% of the bugs in your code.

Which approach do you think works better?

I've seen both the statically typed Python 1Mloc monolithic and the ducked typed 1Mloc micro-service based approach in practice.

I'm telling you the ducked typed micro-service based approach is the way to go.

But you sort of know that "not to write a 2Mloc server in Python", don't you? If we encourage developers to use static typing they will be writing 2Mloc monolithic servers. That's just the type of code that static typing encourages.

Encouraging static typing in Python is putting them down the path of disaster.

Over the years, plenty of people have wanted to show that static typing gives code correctness benefits over dynamic typing. Everyone who tries just falls flat on their faces.

We assume in good faith that statements made in comments on social media are true. If this was an academic paper, then perhaps you would be correct. But on social meda, asking for sources for what is basically common programming knowledge is borderline trolling.

If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct but that is their choice.

There is nothing bold about the claims, knowing the differences between the various typing systems and their advantages and disadvantages is standard stuff.

I mean you could always try to find some sources to try and prove me wrong if you want?

There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount.

Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.