4 ms·
I'm currently migrating a similarly sized Python and Django application to Go but for different reasons. For me it's bit rot. My Python is approaching EOL on t
by buro9 8y ago
I'm currently migrating a similarly sized Python and Django application to Go but for different reasons.
For me it's bit rot. My Python is approaching EOL on this version and needs upgrading to Python 3, and I have a lot of 3rd party code in here that made things simpler to create but over time they've changed enough or disappeared that I now have to take on work there too. Then Django and it's internals have changed a lot in the last 6 years.
My Go code written at the same time (6+ years ago) hasn't had any of it's libraries change so much that I've needed to do anything. Every now and then I pull the next major version of Go and recompile and it's done.
This is all side project stuff but a lot of people use it (monthly average visitors being +250k)... it's non-profit and I don't wish to have to maintain it much.
It worked once, if nothing has changed in the functionality it should keep working... but this isn't as true in non-compiled languages where you need to depend on so much of the environment, let alone build culture that doesn't fully vendor dependencies.
I like Python, but prefer to write code and move forward with other projects.
As to Rust vs Go. I code in both and only picked Go here because a lot of the code in another project I worked on can be used here. I'd probably try Rust if I was starting from scratch now. But I'd be a little concerned bit rot would affect Rust too, it's still quite early for the wider ecosystem.
- ris 8y agoWhat you're actually saying here is "Using Go I'm going to leave the application with unmaintained versions of its libraries", which is a bit of an alarm-bells statement from a security point of view. It's perfectly possible to build a python application that is extremely reliably tied to its dependencies, you just have to avoid the default python package "management" solutions that get shoved down everyone's throat (pip, virtualenv, pipfile, tox and the like). I've been building python projects on top of Nix for years and have managed to maintain stable and reliable results.
- empath75 8y ago“It’s easy to do it if you build your own dependency management system” doesn’t sound like it’s easy to do it.
- ris 8y agoNix is not "your own dependency management system"
- cube2222 8y agoNo, it's really more about the ecosystem and tooling being very stable. Code you've written 6 years ago will most probably work with the current version of Go + updated libraries.
- joseph8th 8y agoNot using Nix but there have been a few libs I've "pinned" in our remote agent by the expediency of simply including the package source wholesale in our app root. Currently just an old version of PySNMP, but there were others before recent upgrades to cx_Freeze. No doubt there were other approaches, but this one is foolproof.
- bayesian_horse 8y agoI'd chose Python 3 migration and updating/removing/exchanging dependencies over rewriting in a different language I know less well any time. And good look finding replacements for Python/Django packages in Go or Rust. Don't get me wrong. You'll find a lot of libraries for those languages. But probably not everything...
- yawaramin 8y ago> I'd chose Python 3 migration and updating/removing/exchanging dependencies over rewriting in a different language They explicitly said they don't want to rewrite. It looks like they have some existing projects in Go that work in a self-contained way and upgrade with minimal effort.
- FraaJad 8y agoIf it is stability you are after, choosing Java on JVM will get you there much better. Java written 20 ago still compiles and works fine today.
- chewxy 8y agoThanks to this post, I went back to see if my oldest large Go project was working: https://asciinema.org/a/cJosP51z0oScKPLmVUhyNKUOj https://asciinema.org/a/cJosP51z0oScKPLmVUhyNKUOj 9 years later, still works.