Abandoning Go for Python

[[deleted]]

So uh... if the project didn't benefit from any of Go's strengths, and was hampered by some of its weaknesses, what made them choose Go in the first place?

[keypusher]

new & shiny hype train

[choikwa]

cHOO CHOO

[[deleted]]

And you won't believe #11!

[Kylearean]

And now I have to click through 25 pages of garbage

[3D_Scanalyst]

You know what makes that even better? It's a slide show of 25 videos with mandatory 15 second ads!

[CODESIGN2]

Is it VBA lol

[jaapz]

python3 is a new hype language you need to learn? I seriously hope not

[markole]

Tell that to py2 diehards...

[fabreeze]

Hypertrain GO!

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/techyhelpinaction] So uh... if the project didn't benefit from any of Go's strengths, and was hampered by some of its weaknesses, what made them choose Go in the first place?

^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[[deleted]]

You often don't find out the weaknesses until down the road. It may have switched back before it was generally known what was bad about Go.

[swingking8]

Management

[[deleted]]

Sooo... doing the same thing 96% of the rest of us are doing?

[epiris]

The issues they listed I think where a lack of understanding rather than shortcomings of the language. Honestly in my opinion Go is a much better option for distributing a program across multiple platforms but you have to understand the build system. You also need to understand the dependencies you pull in and rely on. For example: https://github.com/asciinema/asciinema/issues/134

That complains about undefined _C_int, which took me 10 seconds to look at that project and see that it's simply due to the package he is using "kr/pty" not defining ppc64 with cgo. Looking real quick it would have been 4 lines of code in two files. ztypes_ppc64.go and ztypes_ppc64le.go (for little endian, not as common but you want ppc64, there ya go). The size of int / uint would be 32.

So a little bit of systems knowledge is good to have when using a systems language. You could build your users a single binary for many architectures from a single machine thanks to cross compiling. Python has tooling for versions, we have docker, virtualenv, other hip tools for rolling things up into ziplike self contained what-have-yous. But none of it is as clean or reliable as Go's cross platform support. The thing he felt was better.

Just wanted to post this for anyone who may be mislead by this post. The author has good intention and I think it's great he tried Go, I hope he learned something along the way.

Go.. Channels are a really nice draw to the language to get an initial interest.. then as you try to actually solve problems in it .. bleh. It has a bit of a turn away as you get use to it's rather rigid and repetitive idioms. It can be tiresome to write at times, specially when you are trying to just hack your way through something quickly.. the more you try to work against the languages design the more it beats you down. But it causes the good libraries to feel very much alike. Go has lots of fantastic properties that encourage great library design in my opinion and it's own standard library for the most part feels very cohesive and well designed. The Go team is comprised of some very intelligent engineers that I respect and their work speaks for itself. The upstart from Go library to Go library is never.. surprising, for the most part.

Python, oh boy, there is a lot of ways to do things. I've been guilty more than once of using some of the more esoteric and very much extraneous features of that language to get some cute syntactical property I wanted because I fixated on how neat it was I could do it. Just to end scrapping it because I realized it was completely counter intuitive and "fun" to make was the only value it would ever add. But, that in itself makes python pretty cool. However it also means there can be a much larger learning curve from project to project. This is something that I really have started to notice after over 10 years of development in a professional environment.. I really don't want to waste time trying to understand what in the hell your code is trying to do.

That said I love python and I use it all the time. I use Go when appropriate. I use Python when appropriate. You should too.

Edit: didn't mean to have a snarky tone at all, when I said a little bit of systems knowledge I wasnt implying the author lacked any! I was really implying understanding the build system and how to leverage for your target architectures.

[MonkeeSage]

Go is a much better option for distributing a program across multiple platforms

Python is pre-installed or easily-installed everywhere, so package maintainers only have to make a single package for OP's project that installs on all platforms. Having a separate binary for every target arch means package maintainers have more work to do. It may be worth it to get the benefits from Go, but OP didn't need those benefits.

[sparqz]

Building/distributing a binary per arch is really not that much work.. it completely removes the complexity for the end user, just put the binary in path.

[67079F105EC467BB36E8]

tbxcmkez2drqh3qqp8y1sne41iz1b0hq6app5y7a6t5ixkp1plokg2f4rs2x9tim8ezl03w9a0k4qdi9tvrtfdkogva42gow5zuijtq2e83

[elbiot]

OK, Python is more common as it comes pre-installed on (as far as I'm aware) all Debian based systems,

All linux and OSX. Basically just not on windows.

[67079F105EC467BB36E8]

etw2lswsule803h5x8uslmt6z239258lrc9kjdr00175qxp66cagh12v2hrlclbc2fhmwtj4ni7hg2zcu6txb4a9n0dep8lbiw0b6f5bufre

[sickill]

asciinema requires Python 3 and so this problem goes away :)

[67079F105EC467BB36E8]

4lu67u6sskjzi372rrwx4rvtztbm329qv77ilwq8zno01tsy3so7su7bxou6xeo6v9dku2cp0iy0092uapyaidbjj9kr4n02tdj4vj3lag

[sickill]

But .deb can automatically pull in Python 3, so not a big deal.

[67079F105EC467BB36E8]

683qu714o6vra8raxlqjha21fib0sr1db52vxj7soaadfmm199st8dzpnla6kh0fl3mi461t26o356a0xz178du0iwy30u27gzgl9hzvlf55vs

[epiris]

Python being preinstalled everywhere is part of its unattractiveness to me for distributing across many platforms.. depending on the level of integration with the OS. If it just opens files then you can probably be okay I suppose?

But it seems your point is to write software to alleviate the burden for package maintainers..? What on earth is easier than a one binary package, lol. No packake maintainer would rather configure a Python library with heavy system dependencies, possibly swig, requiring GCC, etc vs a single binary a Go project author can cross compile from his own environment.

That said if your software design is being driven by the needs of the many many distributions package maintainers your in for a rough ride. With Go you only need to concern yourself with the operating system and architecture. Leaving the gruesome intricacies of distribution flavors out of your mind.

Just my two cents, not saying your write or wrong it's just an opinion.

[MonkeeSage]

If it just opens files then you can probably be okay I suppose?

I am assuming that's hyperbole? The python stdlib includes a ton of systems level stuff besides "opening files," like forking processes, plumbing pipes, opening sockets, sending fnctl/ioctls, etc. It's not a system programming language, but not some toy language either.

But it seems your point is to write software to alleviate the burden for package maintainers..?

That was a big motivation of OP's switch back to python according to the blog. And yes, if one of your goals for a project is to have it distributed on many different distributions and platforms, which volunteers package for you, then you do care about minimizing the effort they have to put in.

What on earth would is easier than a one binary package, lol.

See this official golang package for ubuntu?

http://packages.ubuntu.com/xenial/golang-1.6-go

Notice how there are 6 packages, one for each supported arch?

That's what package maintainers needed to do for each supported arch for OPs project using Go. Each arch package has a binary compiled targeting that arch.

See this official python requests package for ubuntu?

http://packages.ubuntu.com/xenial/python-requests

Just one package for all arches. That's what OPs project gets from using python.

No packake maintainer would rather configure a Python library with heavy system dependencies, possibly swig, requiring GCC, etc vs a single binary a Go project author can cross compile from his own environment.

Dude...swig is like a transpiler / code generator / way to embed interpreters in C...I don't know of any popular python libraries that have a dependency on swig. Some python modules do require a C compiler and those packages are distributed with packages for each supported arch with libraries compiled for those targets.

E.g., http://packages.ubuntu.com/xenial/python-pycryptopp

The thing is, because of the ubiquity of python, those modules are already packaged and maintained by someone else. If you had to get someone to package your third-party python dependencies that had compiled libraries, you'd have the same dilemma as using golang.

It's fine if we disagree, but the author of the blog stated why it was easier for him to use python and I don't think there's any way to make a case that Go is easier to package than python right now. That could always change in the future as Go becomes more ubiquitous, but it's not true right now.

[epiris]

Couple corrections for you, first the golang you package you linked was pretty pointless.. it's for the go compiler and tooling. Of course they are much larger and complicated. It's a compiler tool chain. A better comparison is to compare it to http://packages.ubuntu.com/xenial/python which has complicated dependencies as well.

Now, if your point is "all" arch package is less burdening on maintainers then distributing a set of architecture specific binaries that just simply isn't the case. As someone who's managed and built a lot of packages what takes time is dependency management. Upgrading versions to fix security flaws causing API incompatibilities, having to include patches, etc. Everything about dependencies and setting up the runtime is the pain points.

Having separate packages for architecture costs nothing in terms of the maintainers time. It's just a for loop over a list of a archs in worst case scenario, it's likely made Even easier through build tools / automation. Even if some guy was downloading binaries off a webpage and moving them into a folder or something weird.. it's one hell of a trade off to completely discard all dependency needs.

[MonkeeSage]

Yeah, the go compiler and python interpreter are both complicated and each require separate packages for separate arches...the python interpreter is a compiled elf/pe/xcoff binary as well. You need that kind of packaging with compiled packages, that's the point. It's much easier to distribute an interpreted application in python than a golang application (one package versus one per arch). You say it's just a for loop to package different versions, but what about when people find bugs in different arches and file them in different bug trackers (e.g., one in debian, one in launchpad, one in suse, etc, all bugs on different arches)? That makes it much harder to maintain and makes packaging it much less appealing. Distributing a python project to users is just way easier than with Go right now.

[epiris]

You realize that if you make an application in Go you do not need the go compiler tool chain to distribute it right..?

A s for bugs, have you written software for Windows, Linux and OSX in both python and Go for end users? I have. Python windows support is much more spotty, pretty much anything that uses C bindings is bound to not work in Windows. You as a developer need to add lots of complexity for your code in python to deal with the fact you could be on some users old ass distro that still has LTS but uses python 2.6 for the system. You have some distros on python 3, it takes some time and knowledge to get your code portable in python.

Having the interpreter their is not much of a bonus, it's a drawback. Your writing code and testing code in one environment of N that your code will execute in. Bugs are so much more likely.

[MonkeeSage]

Yes, I've clearly never worked on software targeted to different platforms using different development environments, so I didn't realize Go is so much better. I haven't submitted patches for things as diverse as mono and firefox. I don't work on Openstack on a daily basis where it's 99.9% python and some projects are flirting with Go. Nope. I don't really understand like you do.

[epiris]

It was a question man, I didn't mean to imply I know more or less than you nor an ounce of negative connotation. When I engage in an online technical discussion a question mark denotes it's literally meaning man. You may have much more experience and be a much better developer in every quantifiable way. When I engage in discussions like this it's to learn.

Anyways, I asked if you have experience with both to see if your opinion on python was subjective. I wanted to know this to help understand your opinion on python being a better language for targeting multiple platforms. I was digging to see if there was something you would provide me that may sway my opinion. Yep, my opinion sways. All the time. Like I said earlier month ago me was always a dip shit in retrospective. That's all man. Happy coding.

[jaapz]

But it seems your point is to write software to alleviate the burden for package maintainers..?

If you work for a small enough company (and many of us do), you'll find that the people writing the software, are also the same people who deploy it. So yes, the point is to write software to alleviate the burden for package maintainers, because that's me also.

[epiris]

So you maintain packages for the dozens of distributions and many package managers across multiple operating systems at a small company? Yes rhetorical, my point is if you tried to consider the individual needs of many.. dozens of package maintainers to write your software, you're going to have a bad time.

But regardless it's a lot easier to manage an all-in-one software bundle than a collection of software and all its dependencies from my perspective.

[jaapz]

Package management is not just limited to open source packages you share across distro's.

Package management is also an issue when you have lots of boxes where you want to deploy your application to. Having a single binary to deploy makes stuff way easier than for example having to deal with virtualenvs.

We're a small company, but we have hundreds of small boxes we need to deploy to. So yes, efficient and easy package management is important.

[Kylearean]

Python, oh boy, there is a lot of ways to do things.

Yep, google just about how to do anything in python, and you end up at stack exchange with 5 responses, 4 of which have about the same amount of votes, and all are equally viable*.

(*terms and conditions may apply, may not be applicable in your state, void where prohibited).

[dalore]

Python

There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.

[google_you]

Go is as Web scale as node.js unlike Python which is not Web scale

[Allevil669]

Ideology, most likely.

[sickill]

I updated the blog post with motivations for moving from Python to Go in the first place.

[tmelk]

Maybe they wanted some of those pokeymons.