In fairness that approach hasn't really worked in other languages. It was so unpopular in C++ that they actually removed the feature, which is almost unheard of. Java supports it too but it's pretty rarely used in my experience. The only place I've seen it used is in Android. It's unpopular enough there that Kotlin doesn't support it.

Typescript is far nicer than Python though. Well I will give Python one point: arbitrary precision integers was absolutely the right decision. Dealing with u64s in Typescript is a right pain.

But apart from that it's difficult to see a single point on which Python is clearly better than Typescript:

• Static typing. Pyright is great but it's entirely optional and rarely used. Typescript obviously wins here.
• Tooling. Deno is fantastic but even if we regress to Node/NPM it's still a million miles better than the absolute dog shit pile of vomit that is Pip & venv. Sorry Python but admit your flaws. uv is a shining beacon of light here but I have little hope that the upstream Python devs will recognise that they need to immediately ditch pip in favour of officially endorsing uv. No. They'll keep it on the sidelines until the uv devs run out of hope and money and give up.
• Performance. Well I don't need to say more.
• Language sanity. They're pretty on par here I think - both so-so. JavaScript has big warts (the whole prototype system was clearly a dumb idea) but you can easily avoid them, especially with ESLint. But Python has equally but warts that Pylint will tell you about, e.g. having to tediously specify the encoding for every file access.
• Libraries & ecosystem. Again I would say there's no much in it. You'd obviously be insane to use Python for anything web related (unless it's for Django which is admittedly decent). On the other hand Python clearly dominates in AI, at least if you don't care about actually deploying anything.

This is really terrible advice. Sometimes it's better to do that, but definitely not in the example from this article.

If anyone says you should always prefer polymorphism to switches they are a bloody idiot.

I think those jobs are a myth. You probably get like a 20% premium for using COBOL, so if you look up the salary of a Cobol consultant in America it's going to seem like an enormous salary on an absolute scale.

But so is a C++ consultant in America or whatever. Probably not worth learning COBOL for.

Feel free to correct me if I'm wrong, but I have looked once or twice and the COBOL salaries seemed entirely normal.

I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.

And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.

It requires you to sign into a Microsoft account (which I assume most non-nerds do, given how hard they make it to avoid) and have hardware that supports it... But yes Windows enables full disk encryption by default now.

https://www.tomshardware.com/software/windows/windows-11-24h2-will-enable-bitlocker-encryption-for-everyone-happens-on-both-clean-installs-and-reinstalls

https://support.microsoft.com/en-gb/windows/device-encryption-in-windows-cf7e2b6f-3e70-4882-9532-18633605b7df

When you first sign in or set up a device with a Microsoft account, or work or school account, Device Encryption is turned on and a recovery key is attached to that account.

It actually statically links the Rust standard library too. You can also avoid glibc by using musl with a one line change.

Neat hack, but IMO this just loses waaay too many features and UX that Github et al. have. Only masochists will use this. Here are a few I can think of:

1. From a user perspective it's "simpler" in that it saves maybe 1 command... git push (I've still going to want to make a branch), and clicking on the "create a PR" link. But you've also made updating a PR way more of a pain - it was git push, now it's... I dunno some long command I don't remember and looking up a PR number in the web interface?
2. Can't request reviews from people.
3. Can't enforce review requirements.
4. Can't require review comments to be resolved (I bet it's easy to miss review comments!)
5. Can't easily tell who wrote review comments. Are you really supposed to have a conversation by adding // Dave: I agree under comments?
6. Can't add comments to code that doesn't support comments (e.g. packages.json)
7. No CI integration.

I guess some of those are fixable, but overall this seems like a clever hack but very clunky.

I guess it's better than a mailing list at least.

All the old people have learned the old systems (C, Perl, etc) and don't want to have to learn something new, whereas young people are happy to use something newer and better (Rust, Typescript, etc.) because they don't mind learning and don't have a ton of old knowledge to throw away.

Yes that's a big generalisation and there are plenty of exceptions, but in my experience it's broadly true.

I work on an open source project which has a C component. I offered them our closed source C++ version which is way better and fixes a load of issues... Not interested. They learnt C in the 70s and don't see why they should have to change.

Actually that project is a mix of old curmudgeons and young PhD students so there is a bit of a mismatch, but I didn't feel like fighting the naysaying so...

Functional programming doesn't just mean higher order functions. There's a range of other features that it implies.

You don't have to install it on the machine where the script is run. That's the point.

Why is that a hard pill to swallow? Longevity doesn't imply goodness, especially in software. Same for Bash, C and gnu utils.

It also doesn't mean it's a good idea to use it. I would strongly recommend... basically anything else over Jenkins.

Maybe I missed your point there.