Rob van der Linde

Open Source Software Developer

Posts tagged by colander

New interest in Golang

Posted on October 11, 2015 by: Rob van der Linde
Filed under: Go
Tags: python, django, cornice, go, colander, pyramid

This post isn't really about the actual switch from Python to Go (or maybe a little), but mostly it's just an announcement that I have, also I haven't posted anything to my blog for years, which isn't in the best state at the moment and is due for a complete rewrite.

For the past few months now, I have mostly been using the Go programming language for new projects. I had tried using Go a few times in the past and really loved it, got my feet wet and tried various web frameworks, but didn't quite stick to it long enough to go through with it, eventually switching back to Python each time. That has all changed now, as I have started using Go almost exclusively now for new projects, although I still use mostly Python at work which should keep my Python skills sharp 🙂

So what happened to my old Django CMS (rvcms) then? The problem with the old Django CMS is that I seem to be constantly fighting to keep up with Django upgrades and never quite getting there before the next version comes out, and so on. It isn't entirely Django's fault, though it's 6-monthly release cycles can be a bit annoying, at least they do provide LTS releases now which helps a lot. I think the problem was mostly to do with the libraries that I had chosen getting abandoned, so that I had to choose all new libraries and rewrite large parts of my code (at least several times now) to do so, making the upgrade to new versions of Django way too challenging and I just end up losing interest.

The other problem I had with Django, is that my choice to write the CMS admin interface on top of the Django admin interface was wrong (and is actually considered to be a bit of an anti-pattern that is used way too often in Django). Several libraries exist like Grappelli to extend the Django interface, but they may not be compatible with other libraries that also extend the Django interface but in a different way, leading to compatibility problems between libraries. The other issue you get when you start extending the Django interface too much, is that it makes it harder to upgrade to new versions of Django and you often end up having to override internal admin templates.

I tried Pyramid for a bit, Pyramid is great and so is SQLAlchemy, a library for which I have the utmost respect. But unfortunately there isn't a huge community around Pyramid anymore, and Flask seems to be a lot more popular these days. I also had issues with some libraries I chose (colander, cornice) for various reasons. My issue with Colander was that it "wasn't the right tool" for serializing to JSON unless you subclassed every field to "fix" the library, why???, maybe I would have been better off with Marshmallow for serializing to JSON.

My issue with Cornice, is a problem I see with API libraries in general in Python, is that they are made for specific frameworks only. Cornice is made for Pyramid, so you can't use it with Flask. So if I want to switch to Flask, I am screwed and have to rewrite my entire API layer. Likewise, TastyPie and Django Rest Framework are designed for Django only, and Flask-Restful is designed for Flask only.

Why can't there just be a "generic" API library that is framework-agnostic? In Go, libraries often are framework-agnostic, because there are so many frameworks to choose from: Gin, Negroni, Martini, Goji, Ace, Beego, Revel, just to name a few, or some people prefer to use no framework at all and just use the standard library which is really good in Go.

Other than that, I want to start using all the cool new features like websockets, http2 and two way communication, server push, Python can do all these if you run your web application in async mode, but it just doesn't do these as well as Go does, which is designed from ground up to be a modern concurrent language.

I will continue fixing rvcms, as I still have to support it for several older websites, but going forward I will probably continue to use Go exclusively for new projects.