A very interesting point. Coding with AI definitely requires tight, fast loops. I don't have much experience with Rust, but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).
I'm OK with Lisp output, but maybe that just shows how old I am. :-)
I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.
I've been taking Chinese lessons for a number of years, and my teacher described her son as learning characters via pinyin. But it's quite possible (even likely) that the common ones don't require pinyin, and/or that I misunderstood how it's used. Nevertheless, even if I pushed the analogy a bit, I still think this might happen as a bridge between learning to code and agentic coding.
I can see Rust (and to some degree, Go) as the modern outputs from AI. My point about Python being Pinyin is that both of these languages have a relatively steep learning curve for someone without programming experience, and that it might be worth learning Python before doing agentic coding in Rust, much as children in China learn Latin characters before they learn characters.
I don't know if it's that hard for people to go from Python (where whitespace is significant) to languages that use {} and the like. But hey, people only hire me when they want people to learn Python, not when they're moving away from it. :-)
Interesting -- I still think that Python is an easier onramp than TypeScript for new developers. But given the popularity and depth of JavaScript, and the clear advantages (and popularity) of TypeScript in serious development, that's not a bad prediction.
While working on a PhD in technology and education, I thought that it might be worth creating a SaaS for people to teach whatever they want. This was back in early 2008, when such sites didn't exist. I assembled a team, and we made some progress, and even got a commitment from one funder. But I didn't really understand how to manage the team, and everyone was working very part-time on the project, and we didn't really have anything serious we could show, even after a few months. And the funder was only willing to invest if we found a second investor, which we didn't. So we ended up abandoning the project.
I think that we had some great ideas, including guiding instructors in the creation of online classes using the best proven pedagogical tools and theories. You could connect lessons to standards (if you were in a school, or wanted to be associated with one), or could do it free-form, or could use templates of various sorts.
I ended up finishing the PhD, so I can't complain too much! And as I wrote, I was probalby not a good person to run a startup; I'm much happier with my life as a bootstrapped freelancer. But it was hard to realize that I spent a year or so working on this with very little to show for it -- especially knowing that it might have thrived under a more experienced leader.
A lot of people I know, including many of my students, first heard about uv as a lightning-fast replacement for pip. That's what piqued their interest, and that's also more or less where they stopped. Just yesterday, someone was asking me about whether uv knows about handling different versions of Python, or if it only installs packages.
So your points are all valid -- but I'm trying to address pain points people have repeatedly raised, and that I myself experienced, and flatten the learning curve for as many people as possible.
I dunno, every single conference I've attended over the years had at least one talk trying to make sense of packaging -- downloading, installing, venvs, creating wheelfiles, and distributing to PyPI. It was nice to say that you could choose your own tools, but it was a huge, confusing, daunting mess for many people.
I had some thoughts about how things could improve, but the core developers said that anyone with their own ideas had better think through all of the implications, because packaging is super hairy.
The uv folks basically took that as a challenge, and said, "What if we have one package manager that replaces literally everything else in the packaging ecosystem, hiding the stuff that people find confusing or annoying?" Color me impressed; they really did it.
Sorry to disappoint! I can tell you that many people I've met, including those who have read the documentation, kept asking questions about how to use uv. This article is a summary that I came up with, based on my experience and theirs.
System-wide package installs are a weird quirk of my own work, since I'm doing very little product development and lots of one-off classes. I'm not at all recommending that "normal" developers do this, and I make sure to say that in all of the courses I teach.
I teach Python professionally, and constantly get questions from my students about how they should be using uv, and how to integrate it with pip, pyenv, venvs, and the like.
When I shared this post with them, my students said that it clarified things they didn't previously understand, even after reading the documentation. Part of the problem is that the documentation describes lots of options, rather than explicitly encouraging one particular path and model.
So I don't think it's just me; people are excited about uv, but aren't quite sure how to use it. But hey, I could be wrong!
As for your comment about venvs -- I teach them, I demonstrate them, and I use them when I work on programming projects.
I mostly create one-off Jupyter notebooks, which don't (in my opinion) merit their own venvs, because I don't care about locking versions. That said, I'm switching everything such that every class I teach will have not only a GitHub repo, but also a uv project, and thus an implicit venv behind the scenes. I still don't have to worry about package conflicts, but I want to be more in line with community conventions.
In talks, in hallways, and at the expo (i.e., company booths), I'd say adherence was at least 90 percent.
But whenever there was a chance to take the mask off, people did. If there was food around, people immediately ditched the masks and stayed with food or drink in their hand to justify keeping the masks off. I was at one small (10-person) session where everyone agreed to keep masks off, gingerly making sure that no one objected. We then all made sure to have drinks in front of us to "justify" doing so.
And when people went outside, the masks were off. At the PSF member lunch, where we ate together, masks were off as soon as we got food. At the PyLadies auction, where we (again) ate together, people were also without masks. I'll note that the auction took place in the same room where talks had taken place several hours earlier, with strict mask enforcement (and adherence).
Bottom line, people were generally willing to follow the rules. But there was a lot of grumbling about why there should be a mask mandate in 2024, and what the justification was for having one.
I have something of a following (newsletters, social media), gave two talks at PyCon, and even had a booth advertising my training services. So at the risk of sounding like a total egomaniac just for responding, let me say a few things:
1. I absolutely, positively love meeting new people at PyCon, regardless of their background, level, etc. I learn new things from just about everyone I meet, and that's a huge part of the fun for me. I'm frustrated that I don't get a chance to just meet and chat with more people during the conference, and actively try to eat meals with people I don't yet know so that I can get to know them.
2. Part of the greatness of the Python community is that we realize other people, regardless of their fame, are just that -- people. They were unknown at some point, and people were nice to them. So they'll probably be nice to you, too.
3. Every community has jerks, Python included. If someone famous isn't nice to you, then just ignore them from that point on, and concentrate on the numerous nice people. It's not worth getting riled up or upset about it.
I think we can all agree that masking is super annoying. We can also agree that if everyone were to mask 100% of the time, then we would be in a safer world, with less spread of disease.
But we all live with some level of risk. Keeping the risk level at or near zero isn't realistic, or something that most people want. We cross the street, travel in cars, etc.
I find it weird that PyCon had a mandatory masking policy, when medical conferences staffed by doctors and disease experts don't have such a policy any more. And I'm guessing that PyCon's policy was made by well-meaning people who aren't doctors or medical experts.
My suggestion -- and yes, I wrote this in my PyCon follow-up survey -- is that our masking policy follow whatever the CDC, AMA, or a similar body is doing for its conferences at the time PyCon takes place. If the experts require masking, then we should do so, also. And if they don't, then we should encourage people to mask if they need or want to, but we shouldn't force it upon everyone.
In other words: PyCon should make decisions about the conference and Python-related things. Medical decisions should be left to outside experts.
Kit! Your post is great! And I enjoyed getting to know you at the PyLadies auction, too.
PyCon is overwhelming and delightful in every way -- and it just gets more so every time I attend. That said, you managed to see a ton of amazing stuff and people, which is quite impressive.
I've been using Jupyter to teach Python and Pandas to a lot of companies over the years, and Noteable made it so much nicer and easier. I'm very sad to see them shutting down, but I have to assume they would have kept going if they could.
Exactly, no one was asking for a random Meta employee to change things. Rather, three different people filed tickets through an established internal system, and were told that no, there was no way to undo this change.
Actually, I saw that I was banned, and thought, "OK, I'll deal with this another time." I hadn't heard horror stories. I didn't know that there was any such thing as a lifetime ban. It never occurred to me that if I didn't act soon, it would make a difference.
I don't think that it's a sob story at all. I think that it's (a) incredibly funny that they would make such a mistake, (b) a combination of bad UI and bad service on Meta's part, and (c) crazy that even three Meta employees cannot undo such a ban.
So yes: It was my fault that I didn't notice or care faster. And sure, you can call this a sob story. But I think that beyond my personal experience and issues here, this points to some deeper problems with Meta, as well as other large companies that depend on AI.
I'm OK with Lisp output, but maybe that just shows how old I am. :-)
I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.