This is insteresting to me especially since this is a 2005 document. Is there a reason why C++ was chosen instead of Ada which to my knowledge was the gold standard for such software ?
A large segment in this article (which is great overall) focuses on this decision. The short summary is "hiring Ada developers was hard and middleware and tooling were difficult to acquire."
While I've moved through a lot of parts of the software industry and may just be out of touch, I actually feel that this may be less the case today. I've seen a lot of school programs focus less on specific languages and frameworks and more on fundamental concepts, and with more "esoteric" languages becoming popular in the mainstream, I actually think hiring Ada developers would be a lot easier today (plus, big industry players like NVIDIA are back to using Ada since AdaCore have been so effective at pushing SPARK, which probably helps too).
My recollection is that it came down to two factors. Pragmatically, the pool of highly skilled C++ programmers was vastly larger and the ecosystem was much more vibrant, so development scaled more easily and had a lower maintenance risk. By 2005 they had empirical evidence that it was possible, albeit more difficult, to build high-reliability software in C++ as the language and tooling matured.
These days they are even more comfortable using C++ than they were back then due to improvements in process, tooling, and language.
For tco to be really useful you need to think in a non procedural way. Imagine that you don't have loops in your language so you need recursion to do stuff multiple times.
Also even in procedural languages there are some problems that are easier to understand and model if you use recursion, for example tree or graph like structures.
traversing graph or a tree is not a TCO case because it would involve a stack/queue for DFS/BFS, whatever.
I dont want to think in non procedural way, I reserve this nonsense to haskellers, please provide me a valid python use case for TCO :)
Traversing a graph and inspecting each node can definitely make good use of tail call optimization.
For instance: you have a large graph and you are traversing a particular path through it — say a R/B tree seeking a node. You can write it iteratively or recursively. Neither needs to hold more than 1 node reference at a time, the choice is which you prefer to read and write.
I prefer to write that recursively. Sounds like you may not. Observing “well I can write it iteratively so why do I need TCO” is obvious and uninteresting; that’s the point.
Using Django for almost 15 years, almost exclusively, for both business and personal projects. Have tried a lot of other frameworks, nothing clicks so good with me.
My only (small) complain with this release would be that they included the task framework but didn't include a task backend and worker. I'd prefer to wait a bit and include everything in the next version.
Minio is more or less feature complete for most use cases. Actually the last big update of minio removed features (the UI). I am using minio for 5 years and haven't messed with it or used any new thingie for the last 5 years (i.e since I installed it); I only update to new versions.
So if the minio maintainers (or anybody that forks the project and wants to work it) can fix any security issues that may occur I don't see any problems with using it.
Well I didn't mind when they removed it and certainly I didn't consider their paid version which is way too expensive for most use cases.
The UI was useful when first configuring the buckets and permissions; if you've got it working (and don't need to change anything) you're good to go. Also, everything can be configured without the UI (not so easily of course).
> So if the minio maintainers (or anybody that forks the project and wants to work it) can fix any security issues that may occur I don't see any problems with using it.
The concerning language for me is this part that was added:
> Critical security fixes may be evaluated on a case-by-case basis
It seems to imply that any fixes _may_ be merged in, but there's no guarantees.
Yes this is concerning for me too. Hopefully if they don't fix/merge security issues somebody will fork and maintain it. It shouldn't be too much work. I'd even do it myself if I was experienced in golang.
Cloudflare seems to have degrated performance. Half the requests for my site throw cloudflare 500x errors, the other half work fine.
However the https://www.cloudflarestatus.com/ does not really mention anything relevant. What's the point of having a status page if it lies ?
Update Ah I just checked the status and now I get a big red warning (however the problem existed for like 15 minutes before 11:48 UTC):
> Investigating - Cloudflare is aware of, and investigating an issue which potentially impacts multiple customers. Further detail will be provided as more information becomes available. Nov 18, 2025 - 11:48 UTC
> What's the point of having a status page if it lies ?
Status pages are basically marketing crap right now. The same thing happened with Azure where it took at least 45 minutes to show any change. They can't be trusted.
Please read my comment again including the update:
For 15 minute cloudflare wasn't working and the status page did not mentioned anything. Yes, right now the status page mentions the serious network problem but for some time our pages were not working and we didn't know what was happening.
So for ~ 15 minutes the status page lied. The whole point of a status page is to not lie, i.e to be updated automatically when there are problem and not by a person that needs to get clearance on what and how to write.
This is a good article and also reflects my opinons on the matter. All this effort should have gone else where (for example to improve the async job queues framework already introduced in Django 6)
