We have a Django based monolith that I would love to decompose in Go. For me, just the compile time type checking across code base is a big win.
However, the fear of having to replicate Django ORM semantics in Go is holding some of us back. If there is a static tool to build Go ORM from Django model, that could be a potential path forward.
I have heard of the same fear from other developers as well. Lack of slim but powerful ORM and ease of building. I think it requires a mindset shift and understanding that there will be something that you will gain and there will be things that you will lose compared to Django.
I don’t miss the Django ORM much because I never liked the magic metaclass stuff. If you just need basic queries it’s fine but as soon as you do anything complex it becomes it’s own abstraction to learn, and you’re often just better off building your own thing than learning their thing that doesn’t quite do what you want.
Hm the series left me wanting, especially the post claiming success, which had very few quantified metrics of success in it.
Eg in dollar terms how much did they save in hosting? In a linked post they write “We aimed to lower hosting costs, improve performance, and further optimize our already-impressive reliability”. So where are the stats?
This type of serialized blogging about a big rewrite quite often peters out or quietly dies. The authors realize, after a few years of effort, that they’ve merely transitioned to a different architecture with its own warts and drawbacks.
Honestly, it might be a silver bullet. Since we have switched from Go to Python2 we have had absolutely no problems with werewolves at Khan Academy. :)
We have certainly moved on to wrestle with different problems. For instance, we’re doing a lot more AI stuff.
Hi! I work at Khan Academy, and we’re still pretty pleased with how things turned out, to the point where it’s no longer seems novel so we don’t write about it all that much. Also, over time it got increasingly hard to provide simple numbers to an external audience, since it wasn’t a big bang rewrite and switchover, but an incremental one.
It has saved us a fair amount of cloud computational resources, but since then we haven’t continued to run obsolete Python2 nor have we preserved exact equivalency in our Go code after the initial port as we continue to add and improve in Go. This makes it hard to have a comprehensive cost comparison. For instance, a particular endpoint saved us 50% in computational costs when ported directly from Python2 to Go. However, cloud hosting provider computational costs went up so the next month a different endpoint that we ported that was only 40% cheaper in Go, but it saved us the same amount of cost in dollars.
Yeah, pretty much. We invested in GraphQL federation, and it’s been okay.
Our “DB” backend was almost exclusively GCP Datastore, with some PostgreSQL. For the PostgreSQL we weren’t using an ORM in Python2, so we continued to avoid an ORM in Go and chose sqlc with pgx.
This was from 2019.
We have a Django based monolith that I would love to decompose in Go. For me, just the compile time type checking across code base is a big win.
However, the fear of having to replicate Django ORM semantics in Go is holding some of us back. If there is a static tool to build Go ORM from Django model, that could be a potential path forward.
I have heard of the same fear from other developers as well. Lack of slim but powerful ORM and ease of building. I think it requires a mindset shift and understanding that there will be something that you will gain and there will be things that you will lose compared to Django.
I don’t miss the Django ORM much because I never liked the magic metaclass stuff. If you just need basic queries it’s fine but as soon as you do anything complex it becomes it’s own abstraction to learn, and you’re often just better off building your own thing than learning their thing that doesn’t quite do what you want.
Hm the series left me wanting, especially the post claiming success, which had very few quantified metrics of success in it.
Eg in dollar terms how much did they save in hosting? In a linked post they write “We aimed to lower hosting costs, improve performance, and further optimize our already-impressive reliability”. So where are the stats?
This type of serialized blogging about a big rewrite quite often peters out or quietly dies. The authors realize, after a few years of effort, that they’ve merely transitioned to a different architecture with its own warts and drawbacks.
It was, in fact, not a silver bullet.
Honestly, it might be a silver bullet. Since we have switched from Go to Python2 we have had absolutely no problems with werewolves at Khan Academy. :)
We have certainly moved on to wrestle with different problems. For instance, we’re doing a lot more AI stuff.
Hi! I work at Khan Academy, and we’re still pretty pleased with how things turned out, to the point where it’s no longer seems novel so we don’t write about it all that much. Also, over time it got increasingly hard to provide simple numbers to an external audience, since it wasn’t a big bang rewrite and switchover, but an incremental one.
It has saved us a fair amount of cloud computational resources, but since then we haven’t continued to run obsolete Python2 nor have we preserved exact equivalency in our Go code after the initial port as we continue to add and improve in Go. This makes it hard to have a comprehensive cost comparison. For instance, a particular endpoint saved us 50% in computational costs when ported directly from Python2 to Go. However, cloud hosting provider computational costs went up so the next month a different endpoint that we ported that was only 40% cheaper in Go, but it saved us the same amount of cost in dollars.
Hey, I work at Khan Academy in the backend. A few years on, and the transition to Go from Python2 has continued to save us time and money. AMA
With the currently available tech stack, would still have taken the same route or done something differently?
What was your DB backend, more specifically, did you use Django and it’s ORM before the transition?
Yeah, pretty much. We invested in GraphQL federation, and it’s been okay.
Our “DB” backend was almost exclusively GCP Datastore, with some PostgreSQL. For the PostgreSQL we weren’t using an ORM in Python2, so we continued to avoid an ORM in Go and chose sqlc with pgx.