Why we switched from Python to Go
getstream.io
Why we switched from Python to Go
1–10 of 406 posts
Re: Why we switched from Python to Go
#2> Python, Node and Ruby all have better systems for package management
Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages.
Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're going to have dependency problems of some kind. I'd rather deal with those problems at compile time than hit an edge case during deploy or in prod.
Re: Why we switched from Python to Go
#3Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compared to Python, but after a few attempts (perhaps halfhearted), I never felt "Go" was a suitable replacement.
Re: Why we switched from Python to Go
#4>Reason 3 – Developer Productivity & Not Getting Too Creative
There is a time and place for these tools. A part of managing a team is ensuring there are good practices around "getting creative" and that there is a clear rationale. Python's metaprogramming came in handy for helping us provide a high level syntax to work with our data model.
Re: Why we switched from Python to Go
#5> Another great aspect of concurrency in Go is the race detector. This makes it easy [emphasis mine] to figure out if there are any race conditions within your asynchronous code.
Am I reading correctly?
Re: Why we switched from Python to Go
#6Re: frameworks
My experience with the language (building multiple production systems) is that the language itself is sort of it's own framework. You don't need to add much to build an application with the standard library. Which is a huge plus and makes things simpler.
Re: Why we switched from Python to Go
#7A nice write up generally. I just feel he should also mention the classic static vs dynamic typing thing. From my perspective, teams switching to Go — from dynamic typed language such as Python — really appreciate the additional compiler help it provides ;)
Re: Why we switched from Python to Go
#8I would agree with some of the points - speed (which is stretched over two points), concurrency, and the ability not to do magic as easily, but several of the points (compile time, available developers, strong ecosystem) are not a "versus Python" at all but rather against other languages.
Personally, I see a language like Go and Python as solving different spaces. I wouldn't write a lot of website business logic in Go, and I wouldn't write a low-level TCP redirection daemon in Python.
Re: Why we switched from Python to Go
#9> Python, Node and Ruby all have better systems for package management Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages. Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're…
This has been a massive win for us vs languages that require you to haul around a runtime and other dependencies.
Re: Why we switched from Python to Go
#10> Another great aspect of concurrency in Go is the race detector. This makes it easy [emphasis mine] to figure out if there are any race conditions within your asynchronous code. Am I reading correctly?
You know there are but that's the end - still not easy to reason about them haha!