That's a really good point actually. If you're self hosting, you're already eating some cost by having people, probably in-house, doing the work but the price difference must be quite large and they should use it to support the project.
The Agile Manifesto says "People over process", this can be interpreted in many ways. But ideally you follow the 80/20 rule and have clear cut processes for the most frequent cases and/or liability/law/SLA stuff you can't do without. But you should have fast escape hatches as well imo where a good engineer having admin access on a platform or deploying a hot-fix is also possible.
It's an interesting article because tech articles rarely revisit the past for what kind of decisions were made and why. Thanks! Also always cool to see a Wingo article because I get exposed to a field I know very little about (how garbage collection works).
Can you explain what reproducible mean in this context? Does that mean that you can recompile everything from "scratch" or does it have a deeper meaning?
Reproducible builds ensure that you can build the same binaries with the same source code. Nothing like the current date for instance gets in the way of getting a different build.
This allows independent people to check that provided binaries don't contain malicious stuff for instance. Ultimately, it lets you download binaries instead of rebuilding everything yourself locally if the binaries have been independently reproduced.
The provided binaries may still contain malicious code but it guarantees that no malicious code has been inserted in between the build process of the published code. So if your binaries contain malicious code, you can be sure that all other users of the software version are affected, too.
does anyone practice dual build pipeline? eg: 1 by your devops team and another one by your security team and compare binaries hash later. To verify everything is reproducible.
What bothers me, for example in Python, with the function coloring is that it creeps everywhere and you need to rewrite your functions to accommodate async. I think being able to take and return futures or promises and handle them how you wish is better ergonomics.
Yeah but to be fair, that can have adverse effects if you, say, busy wait.
The sync code might be running in an async context. Your async context might only have one thread. The task you're waiting for can never start because the thread is waiting for it to finish. Boom, you're deadlocked.
Async/await runtimes will handle this because awaiting frees the thread. So, the obvious thing to do is to await but then it gets blamed for being viral.
Obviously busy waiting in a single threaded sync context will also explode tho...
As mentioned in the article, others might have different constraints that make the GIL worth it for them; since both versions of Python are available anyways, it's a win in my book.
Nice that someone takes the time to crunch the number, thanks! I know there's some community effort in how to use free-threaded Python: https://py-free-threading.github.io/
I've found debugging Python quite easy in general, I hope the experience will be great in free-threaded mode as well.
My main interaction is from the GUI where I just leave it open for days at a time. So this article stems from some of the frustrations I had using it in the terminal and not finding the same behavior I was used to.
reply