MIT's report on AI and education is one of the smartest and deepest takes I've seen to date on the subject. But it's not a "we'll allow X and we'll forbid Y" report. Rather, it's saying that AI can and should profoundly change how we teach and learn, and that the sooner we start to experiment, always keeping people as our central focus, the better.
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.
> but I had heard that the compiler is slow (because it's doing so much thinking and checking in advance).
The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.
> one that's optimized for such tight loops, and another that does thorough checking
I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?
I mean if we're getting really serious about ai-first development, we might be able to get away with a ton of micro services written with clear, simple apis to communicate all in a giant mono-repo managed by an army of agents. That way the full surface any one agent has to touch is small, compile time of each individual service is very fast, and services can be hand-written if super critical.
Anyway, I've played around with the idea a bit so far, and it seems that current agents/harnesses use way more tokens with that architecture.
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.
The problem with Rust is that, AI aside, the learning curve is steep. Even senior engineers need to wrap their head around Rust for several weeks.
You can pick up Go or Java in an afternoon. It’s fast, it mostly makes sense. Unless you do very specific low level things I don’t particularly see Rust becoming the de facto norm for the vast amount of enterprise code
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.
One thing that Python has that virtually no (well okay groovy and nim do too) other programming language has is whitespace for blocks rather than visible braces (or even BEGIN/END ala Wirthian languages). That's something much like line numbers in classic BASIC that introduces a roadblock when learners move on from it.
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. :-)
To what extent do you see Python drifting toward stronger typing? I ask because after 10 years without touching a single line of Python, I recently worked on a Python code base and I was very positively surprised by the static typing that's available in the language now. Not even necessary to to reach for additional tooling like JS and TS.
Drifting? I think it's there. basedpyright is awesome and super fast. Our latest services are all CI gated by type checking. Early in my career you'd hit so many dumb errors running your code - NoneType, attribute, value, and type errors. I'd say that's been cut over 95%.
What tooling are you thinking of that’s part of the language? I don’t think CPython ships with a type checker, does it? People typically use mypy or pyright and neither or these are part of the language.
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.
