Jacob Kaplan-Moss, one of the BDFL’s for Django has published the text and slides for his upcoming talk(s) “Snakes on the Web” at PyCon Argentina and PyCon Brazil. Jacob says that he’s trying to answer three questions:
- What sucks, now, about web development?
- How will we fix it?
- Can we fix it with Python?
There’s some good stuff in here, and it’s definitely a worthwhile read.
Jacob is in South America, which means he won’t be at DjangoCon next week. I was disappointed about that before I saw his talk, and I’m even more disappointed now. I’ll be giving the last keynote at DjangoCon, and I’ll be discussing some thoughts and ideas for where Django (and other web frameworks) might go next. It would have been a great opportunity to carry on the conversation in person. I guess we’ll be doing by blog instead.
One of the topics that Jacob covered in his talk was concurrency, and he pointed to my OSCON talk on concurrency constructs as something that has influenced his thinking. I do think that he got the wrong idea from my conclusion. At the moment I don’t see a clear solution for concurrency, but I don’t believe that the situation is hopeless, either. I think that we are looking at a period where we have a lot of experimentation, and I think that’s a good thing. It is way premature to say that we have a solution, and I’d rather people keep experimenting.
I have some more thoughts on some of Jacob’s points, but those are in the keynote, so I’ll save those until after I’ve actually given the presentation at DjangoCon on Thursday. I suspect that the other keynote speakers, Avi Bryant, and Ian Bicking to have some thoughts in this general direction as well. I think it would be great to have an open space on these topics sometime on Thursday.
I, too, don’t agree with much of what he said about concurrency. I don’t think Twitter is shared-memory; it’s message-passing, i.e. shared-nothing. I don’t think we can scale on manycore without going to shared-nothing. I don’t think Python is some sort of desert devoid of concurrency innovation: ZODB is a persistent STM (with optimistic synchronization, just like the more recent STMs, but an unsound model of conflicts — it doesn’t log your reads in order to know what data you depend on) and Stackless is a playground for Actor-based computation. Both of these have been in heavy production use for quite some time.
However, they’re kind of researchy, and Python isn’t about being researchy. So they don’t make it into the core.
It would be great to be able to chat about this stuff with you in person. Wish you were here visiting Argentina!