> basic rules that had been in place for ages. Things like: [...]
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
IMO the ubiquitous Yes/No/Cancel is even worse. No and Cancel are too conceptually close. Doesn't help that these usually show up when you're about to lose all your unsaved changes.
We've got big screens now! use more words! Save changes/Discard changes/Don't quit.
No, determinstic scheduling is not a property of async python.
Yes, the stdlib asyncio event loop does have deterministic scheduling, but that's an implementation detail and I would not rely on it for anything critical. Other event loops - for instance trio [1] - explicitly randomize startup order so that you won't accidentally write code that relies on it.
It's been a stable (and documented) behavior of the Python standard library for almost a decade now. It's possible it may change--nothing is ever set in stone--but that would be a large change in Python that would come with plenty of warning and time for adjustment.
And then one day, Astral creates a new Python implementation in Rust or something that is way faster and all the rage, but does this particular thing different than CPython. Whoops, you can’t use that runtime, because you now have cursed parts in your codebase that produce nondeterministic behaviour you can’t really find a reason for.
and then all the serverless platforms will start using Astral's new rust-based runtime to reduce cold starts, and in theory it's identical, except half of packages now don't work and it's very hard to anticipate which ones will and will not and behold! You have achieved Deno
Well, in my early days programming python I made a lot(!!) of code assuming non-concurrent execution, but some of that code will break in the future with GIL removal. Hopefully the Python devs keep these important changes as opt-ins.
How do you differentiate between something that "happens to work due to an implementation detail" and a "proper feature that's specified to work" in a language without a specification?
> What makes anyone start a new project and think “I know, I’ll use Azure!”?
Because your org is likely already paying for O365 and "Entra ID" or whatever they call it nowadays, and so it seems like this will all integrate nicely and give you a unified system with consistent identity management across all domains. It won't - omg, believe me it will NOT - but you don't find that out until it's too late.
> One of the few reliable barometers of an organisation (or their products) is the wtf/day exclaimed by new hires.
Wellllll ... my observations after many cycles of this are:
- wtfs/day exclaimed by people interacting with *a new codebase* are not indicative of anything. People first encountering the internals of any reasonably interesting system will always be baffled. In this context "wtf" might just mean "learning something new".
- wtfs/day exclaimed by people learning about your *processes and workflows* are extremely important and should be taken extremely seriously. "wtf, did you know all your junior devs are sharing a single admin API token over email?" for example.
> http.server isn't a production-ready webserver, so people use Flask [...]
Nit, but relevant nit: Flask is also not a production-grade webserver. You could say it is also missing batteries ... and those batteries are often missing batteries too. Which is why you don't deploy flask, you deploy flask on top of gunicorn on top of nginx. It's missing batteries all the way down (or at least 3 levels down).
Appreciate the nit. Had no idea that Flask wasn't production-grade. Yeesh.
I really don't miss this part of the Python world. When I started on backend stuff ~10 years ago, the morass of runtime stuff for Python webservers felt bewildering. uWSGI? FastCGI? Gunicorn? Twisted? Like you say, missing batteries all the way down, presumably due to async/GIL related pains.
Then you step into the Go world and it's just the stdlib http package.
Anyway, ranting aside, batteries included is a real thing, and it's great. Python just doesn't have it.
Consider that the insane growth in the cost of living - especially childcare - combined with wage stagnation means that now the vast majority of families have 2 parents with full-time jobs, keeping them away for their families for much longer than before. Consider that childcare is much, much harder to even get into now than in decades past. Consider also that "EdTech" means that nearly every child needs to be on an internet equipped-device at all times.
But sure, "Parents often give too little fucks for long term welfare of their children", that's definitely it. Parents just hate their kids! What a useful perspective you've brought to the discussion.
Look, I am in this category too, and all that high cost and parents far applies for me too. I live in Switzerland, country of many wonderful things in society but state helping young parents ain't one of the strong points, in contrary. Both me (cca senior banking position in IT) and my wife (doctor) have intense time consuming jobs. All family is very far and can rarely help.
Still, given all that, I don't do cheap excuses like that. Its pathetic and weak and simply untrue. Things are harder but thats it, not impossible like your side of argument wants to conveniently claim. Quality time well spent with kids is highly proportional to outcome of raising efforts. No way to hide from that simple fact, and nowhere to hide from results of parenting, everybody can see them in plain sight.
But if you setup your life so that pathetic things like career are your upmost importance and you have no time nor energy for anything else, those are your choices and thats fine. Just not getting why folks then have kids, just to skip on actually raising them and then whine how unruly they are, raised by toxic groups with no role models. Having and raising kids is not some fucking checkbox to tick and move on, its 20+ years full commitment and biggest achievement in one's life, or biggest failure. Worth some proper effort, no?
I'm like 3 sentences in and already things do not quite make sense.
> Calling [socket] operations in the wrong order [...] is undefined behaviour in C.
UB? For using a socket incorrectly? You sure about that?
> Documentation — trust the programmer to read the man page (C, Rust).
I'm sorry, are they saying that rust's socket interface is unsound? Looks to me like it's a pretty standard Rust-style safe interface [1], what am I missing?
True. So sad to think that hackers are exploiting - and yes, there can be no doubt, this is EXPLOITATION - weaknesses in coin-operated services. I weep to think how far has this once-noble vocation has strayed from its roots ...
John Draper and his fellow hackers were EXPLOITING coin-operated payphones and switchboards in the 60s, so I'm not sure how far back you have to go to reach the noble vocation you describe.
I am going to add my favorite here, just to rant into the void. A dialog box's options must never be Ok/Cancel. These are not the same sorts of things. "Cancel" is a verb, "Ok" is a noun (in this context). Even if "Ok" is taken to mean the verb "acknowledge", it is still not an alternative to cancelling.
99% of these dialogs should be "[Verb]/Cancel": Change "Ok" to a verb or short phrase indicating the action that will be taken if you press it. Don't do the action if the user hits "cancel". The verb should be something specific like "Delete file" or "Terminate process" and not something useless like "proceed".
reply