This sort of attitude is the reason why the world doesn't move away from awful solutions. It is a testament to the lack of ability to see beyond your own nose.
A lot of people who use Python, don't have the luxury of it being their "daily driver for years", so the conflicting documentation, decision paralysis and other problems that come with it end up being a huge time sink.
A lot of non-programmers are being forced to use Python for various automation tasks. A lot of the CAD-software that construction engineers use, support Python-plugins. Network admins that have been configuring switches and routers on CLI for decades now have to configure them using Python.
Look at "cargo" to see what the world could be like.
Because there are a lot of programmers that read Hacker News and some of them have interests in particular things. That's why you see titles such as "Learn polynomial regression with Tensorflow" or "How do do HFT with Python".
I don't see any reason why people who write these tools in Ada shouldn't add that to the headline as well. People who are interested in Ada would be even more likely to read the article then.
Consider this. If a program is written in Python, and becomes popular, it is usually a matter of time before it gets rewritten in, and replaced by an implementation in a faster language.
There are fast implementations (C) and there are somewhat safe implementations (Python, Java, ...). If I were to place Rust in this hierarcy - it is both fast AND safe, and there's rarely a good reason to replace it, so you've software that's already at the top of the hierarcy. This means that the particular implementation is likely to be the one that doesn't get replaced.
"...in Rust" has a lot of implications other than being an exercise in marketing.
You're right, it is a BSD is dying post, only a decade later.
I agree with everything that you said. In an ideal world, we could all convince our colleagues that Docker and SELinux and Apparmor and such things are crap, and that everyone should be using OpenBSD alternatives. This is nothing but wishful thinking, however.
I wish the industry (and Cisco) would know about OpenBSD and wish to use it, but alas, this is not the case.
Yes, the main use is a fairly narrow part of possible uses, and introducing a whole new OS, package system and command set just because you prefer pf over nftables seems like something most of your colleagues would be a little disgruntled with.
2) Yes, I agree that OpenBSD exists in another space, which is fairly small. Is it worth introducing "unknown" tech to your team, though? I mean, is pf that much better than netfilter's nftables, to introduce something relatively unknown?
3) I agree. And "whatever platforms they support" means Linux nearly always, and very rarely OpenBSD. So you'll have to deal with Linux, but OpenBSD is optional and introduces additional complexity/stuff others on your team don't know about.
I think OpenBSD is better technology, but most of your colleagues will consider it unfamiliar territory, you'll miss out on new technology, etc.
As much as I love OpenBSD, it's one of those things that doesn't work for enterprise.
1) Commands have different switches. This is really annoying since you're probably using GNU/Linux at your day job.
2) It doesn't support all the new and fancy container/automation stuff that your colleauge is super stoked about.
3) Most companies haven't even heard about it, which causes certain problems. Example: I was working for a company that had a collaboration with Cisco, and we needed some binary blob in order to provision networking equipment. Getting this to work on OpenBSD was ten times as much work as making it run on Linux.
4) If you share your laptop with anyone, e.g. your wife or your parents when you're on holiday, they'll be a lot happier with Ubuntu.
In a perfect world, everyone would be running OpenBSD, but in the world as it is now, Linux is "better".
A lot of people who use Python, don't have the luxury of it being their "daily driver for years", so the conflicting documentation, decision paralysis and other problems that come with it end up being a huge time sink.
A lot of non-programmers are being forced to use Python for various automation tasks. A lot of the CAD-software that construction engineers use, support Python-plugins. Network admins that have been configuring switches and routers on CLI for decades now have to configure them using Python.
Look at "cargo" to see what the world could be like.