Stackoverflow started failing when Jeff left. While he had a big hand in the whole mantra of being more of a Wiki than just Q&A, I feel his sense of community wouldn’t have let it get so bad.
Then all of the OG engineers left (I hope Nick Craver is doing well, his blog posts were incredible), an investment company took over, and whatever good will and vibe that was left melted away.
I’ll still occasionally find a good answer there. But it has zero future of making answers available for future good questions.
Astral folks that are around - there seems to be a bit of confusion in the product page that the blog post makes a little more clear.
> The next step in Python packaging
The headline is the confusing bit I think - "oh no, another tool already?"
IMO you should lean into stating this is going to be a paid product (answering how you plan to make money and become sustainable), and highlight that this will help solve private packaging problems.
I'm excited by this announcement by the way. Setting up scalable private python registries is a huge pain. Looking forward to it!
I've been wondering where the commercial service would come in and this sounds like just the right product that aligns with what you're already doing and serves a real need. Setting up scalable private registries for python is awful.
Perceived only at this stage, though the kind of volume we’re looking at is 10s to 100s of millions of jobs per day. https://github.com/riverqueue/river/issues/746 talks about some of the same things you mention.
To be clear, I really like the model of riverqueue and will keep going at a leisurely pace since this is a personal time interest at the moment. I’m sick of celery and believe a service is a better model for background tasks than a language-specific tool.
If you guys were to build http ingestion and http targets I’d try and deploy it right away.
Cloudtasks are excellent and I’ve been wanting something similar for years.
I’ve been occasionally hacking away at a proof of concept built on riverqueue but have eased off for a while due to performance issues obvious with non-partitioned tables and just general laziness.
Agree. Rounding most of the advice to providing an executive summary is about right.
If you’re not fully confident and think an experiment is worth while, lead with that, and provide assurances there are mitigations in place or a decision is easy to back out of. That’s still doing the work.
If you want an easy decision, you need to do the work. Not expect others to get into all the detail you did. There’s still room for those decisions - they’re just not as quick/easy.
I often give similar advice to colleagues that ask me for pointers on getting their recommendations approved.
"Make it as easy as possible for them to say yes"
Don't dump 14 paragraphs in front of someone expecting them to get onto the same level that you've been after many hours of studying a problem. If you're confident in your approach (and you should be, if you want an easy yes!), then be succinct, briefly describe the problem and why your solution is correct. Optionally link to a document that has more information if a reader wants to go deeper. Make sure you've already gained "approval" from your other team mates or product owners.
"We're going to solve X by doing Y. Team are all onboard. Proposal document is at [link] if you want the detail. Going to begin on Tuesday unless there's any more feedback we need to address."
Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.
What I was hoping to be able to do was run our existing cpython project on graal to try and benefit from whatever speedups the jvm (or, if possible, compiling to a native module) would provide, rather than build with the jvm specifically in mind from the get go.
Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away.
- Maturin doesn't support the graal interpreter, so no Py03 packages
- uv doesn't seem to run, as `fork` and `execve` are missing from the os package?
- Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add additional IFDEFs
I don't think Graal is going to be a viable target for large projects with a huge set of dependencies unfortunately, as the risk of not being able to upgrade to different versions or add newer dependencies is going to be too high.
It's impressive what it does seem to support though, and probably worth looking at if you have a smaller scale project.
Rye was started by Armin as a collection of existing tools (mostly) with a frontend similar to cargo.
Then Astral came out with uv which aims to be a frontend into a collection of their own tools similar to cargo.
Armin and Astral agreed for Astral to take over Rye some time during uv development with (I assume) the goal for uv to fully replace Rye.
Use uv. As of 0.3.0 it covers most of rye now anyway. Especially if you’re writing projects and not consumable libs/apps (I haven’t used uv for anything other than package management so far).
This is what jumped out to me reading this article too - unashamedly admitting to having gaps in knowledge that some others might take for granted.
Bucketing some of those gaps as “probably useful but not to me right now” is also great. It shows a purpose to focus on what matters right now, with a hint to return to when it does pop up again later.
Lots of folks I work with and respect sometimes get trapped in the weeds having to understand every little thing. It’s good to be curious, but sometimes filing it away for later and shipping is more important now.
Then all of the OG engineers left (I hope Nick Craver is doing well, his blog posts were incredible), an investment company took over, and whatever good will and vibe that was left melted away.
I’ll still occasionally find a good answer there. But it has zero future of making answers available for future good questions.
They took the fun away.