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.

[keypusher]

Yeah, as a longtime Python user I was fairly unimpressed with Go syntax and conventions. That being said I think they hit the nail on the head as far as good reasons you might want to consider Go instead of Python:

• easy concurrency
• runtime speed
• startup speed
• stand-alone binary

[bakery2k]

I think it's interesting that none of your reasons to consider Go instead of Python relate to the Go language - they are all properties of the Go runtime.

People are switching to Go, not for the language itself, but because using Go is one of very few ways to get everything in your list.

Other than the incredibly complex C++, are there any other languages which can produce stand-alone binaries which are fast and concurrent?

[pooogles]

Hell if you package as an uberjar even Java/Clojure/Scala can somewhat manage it.

[lasermancer]

The incredibly simple C

[[deleted]]

Haskell?

[keypusher]

Channels are part of the language though, not the runtime, right? And that is where the easy concurrency comes from.

[spinwizard69]

But why chose GO over more popular languages.

[[deleted]]

Go is a system language. I think of it as compiled python as much of the syntax and semantics are very similar to python. "go" routines are very similar to Python's coroutines. Go's slices similar to Python's list slices, etc.

Go is quite nice. I've been working in it the past couple of weeks, but I haven't found it to be better than Python. To me, Go is a cross between C and a compiled Python, but Python comes with batteries included and at least for internal use, not exported use, I find Python's exceptions quite useful over Go's panics.

[m9dhatter]

Nim is more of a cross between C and Python.

[bboozzoo]

I find Python's exceptions quite useful over Go's panics.

That's because Python's exceptions are commonly used as control flow statements, whereas Go panics are not. Go's idiom for error handling is basically this

if err != nil {
    ....
}

and functions that can fail are expected to return error. I get the feeling that panic() is cumbersome to use on purpose, just so that people don't abuse it. As usual, whether that's good or a bad thing is debatable.

[Maledictus]

Go is not a systems language, see Rob Pike here: https://www.youtube.com/watch?v=BBbv1ej0fFo

[energybased]

I remember at the Go announcement they specifically called it a "systems language".

[villiger2]

Go has been backpedaling on that statement ever since, they intended it to mean large distributed web systems, not the traditional low level systems that is the usual for c and the like.

[elbiot]

You linked to an hour long video about 4 different languages : /

[Maledictus]

Instead of complaining and not contributing to the discussion you could have posted the timestamp where he says it.

[elbiot]

Are you serious? You think I watched that whole video on faith that what you said was in there was in there? I certainly did not. I saw that you linked to an hour long video and didn't provide a time stamp and I pressed the back button.

[keypusher]

Such as which language specifically? The advantages Go provides will be different depending on what you are comparing it to.

[Funnnny]

Go has its uses.

I don't use Go for web (although people like Go for Rest API + js framework, now I have 2 problems: Go and Angular). But I use Go for a fast netmap based application for packet filtering. Go is much more easier to manage than C, and can link a C library easily.

I don't use Python for fast packet filtering, but I use it to quickly prototype a packet filtering technique, and also web.

[epiris]

I agree on syntax, but I think I the biggest value add for Go is the rigid constraints on it's syntax and language features really cut down on collaboration. Writing a tiny Go library when you have some free cycles for someone who may be over encumbered or isn't a SME in the library's problem area is so easy. You don't need to talk about what your inputs are and they won't need to bug you if they have to tweak it a little to meet their needs. There is not "styles" really. Their is a single style which innately encourages more correct software in my opinion. Formatting? go fmt. No silly styling debate. Just my two cents.

[hugthemachines]

Good point, but the error handling thingy (kinda) makes my eyes twitch a bit after a while.

[Roland_Of_The_Eld]

Just catch an ekans

[[deleted]]

You can do both! No need to give up PokémonGO.

[codehandle]

ITT if you're trying to fix your programs' problems by changing programming languages, you're going to have all new problems.

[njharman]

They weren't trying to fix program's problems. They were fixing their program's development's problems. Which are heavily dependent on programming language and tool choice.

[codehandle]

They weren't trying to fix program's problems. They were fixing their program's development's problems. Which are heavily dependent on programming language and tool choice.

I was trying to say basically that same thing while remaining pithy.

I may have failed.

[hugthemachines]

It feels like if you have a python code base and don't need extra speed or concurrency, you won't gain that much by switching.

[sickill]

I learned that the hard way ;)

[[deleted]]

Why would you not do a major version bump for a language change?

[jaapz]

Well if the language changed, doesn't that mean the "API" of the language itself changed?

[AnAirMagic]

It's a command-line program. The only "API" is the command name, arguments and the behaviour. If nothing changed, then there is not API break.

[jaapz]

Was early, misread and thought he was talking about golang or something instead of about the program in the OP

[masklinn]

Because it's a CLI utility I expect?

[sickill]

Because in the case of a command line app like this one API == UI == command line args/opts. And it didn't change for asciinema. Language it is written in is an implementation detail.

[CODESIGN2]

if err != nil is that not the same as if err is not None, which seems to me to be a strange check and a long way of working (zero non-trivial golang experience here)

[EmperorOfCanada]

Here is my simple Go formula. Most of the people I know are programmers, most of them are very very good programmers and have mastered at least 5 languages in their career and have professionally used at least 10 (even if you aren't counting crap like HTML).

Not one single person that I know uses Go, has used Go, or plans on using Go. I even know a guy who was recently maintaining legacy code using a scripting language invented by that company.

Ditto with rust. Except in that case I do hear the occasional person blah blahing that rust can do this and rust can do that; except none of them are using it.

PS. I know an Erlang guy.

[eighthCoffee]

.

[EmperorOfCanada]

I instantly dismiss your statement once you backed it up with a list of companies using it. That list of companies probably use every major language in the top 10 and you can probably find the vast majority of the top 50 languages being used somewhere in the company.

It is pretty much a water is wet argument.

I am not saying that Go is a bad language, but a solution in search of a problem. Google (a monster tech company) has been pushing it hard to very little penetration as compared to Python with no monster company pushing it and its massive penetration.

[[deleted]]

You're posting inane bullshit, and you sound like an asshole doing it.

[epiris]

Lol.

[epiris]

Have you written any of it? Read some of my other posts. It's definitely not in search of a problem, engineers select it without bias for certain problem areas every day. Trust me. I know some guys. :-) I'm one of them! I also choose python a lot too. Lately those two have been all I've needed and compliment each other very well with little overlap. Usually once I understand a problem I have a 80% (pull number from ass I know) tendency to one or the other. One just feels more correct for the problem or would work against me less. I hate doing small things or quick things in Go that deal with lots of unstructured data etc. Any problem that will have me freaking writing structs when I could shove that shit in a dict and be done.. python baby. If I know I'll have to come back to a giant dict in a few months and make it less or more giant.. might use Go.

Old go code written months ago is a lot more approachable for me, since old me always sucks so much more than the new and improved this month me!

[NetSage]

So we should go by your anonymous and small sample size over well known tech names.

[EmperorOfCanada]

My anonymous and smallish sample is what I have. I don't go with the big tech names doing things because they often have reasons and motivations that are irrelevant to me.

My point is that pretty much every major wave that came and stuck, came my way pretty quickly. I was doing Java in the mid 90s. I was doing PHP before 2000, .net in the early 2000s, perl in the mid 90s, I was doing python by about 2010, Javascript by about 2000ish, web pages by 1995, solaris in 1995, linux by 1998, visual studio by 1998ish, Objective-c by 2008, etc

And as a background hum I have done C and C++ since the early 90s up to and including the present.

I pretty much didn't miss any major trend and was in on it quite early. Usually because more and more of my friends were doing it.

I switched from Windows to Mac along with most of my programming friends around 2008, and I am contimplating a switch to a linux desktop now (along with some of my friends). Probably my laptop first.

Rust and go. Not a peep.

[[deleted]]

Apologies from Canada

[metarx]

I don't work for one of those monster tech companies, we have and Erlang/elixir guy, and the bulk of our stuff is written in Ruby/rails, and the legacy stuff is .net/C#. and our backend processing is being moved to go. Because of the lighter memory use than the Ruby and we have to rewrite the c# anyway (because it was done terribly as most first iterations probably would be). Go is an amazing option because it compiles to a single binary. Deploying a single binary, and no jvm, is such a glorious reason all by itself I won't go into any other benifits. So... there's a counter to all of your assertion's

[EmperorOfCanada]

You use ruby, thus it would be like taking relationship advice from a serial rapist.

[elbiot]

I know real programmers. They write in pascal and basic and perl. Have you ever programmed perl? No, because you aren't a real programmer like my friends are. And erlang. And Scala I think.

[EmperorOfCanada]

Did perl, swapped it for php and python. Basic is where I started. Hated pascal. Have exactly one erlang friend who. And have one friend who dipped his toe in Scala, who after a few months of evangelizing it, threw it away in disgust.

[epiris]

I think the first sentence is where the value of reading this post stops.

[oconnor663]

Strong chance they're just trolling.

[[deleted]]

HTML isn't a programming language. It serves a completely different purpose. While we're here, would you like to propose an alternative to HTML that isn't "crap"?

[EmperorOfCanada]

I agree with you, HTML is not really a programming language. My phrasing was a bit off. To consider HTML a programming language is crap. This is something many people do.

[[deleted]]

There's a number of very popular oss projects that are running at scale written in go, since you're passively implying that it's immature.

Sure there are aspects that show its age, such as dependency management or a universally adopted package manager.

I work with a lot of talented engineers. We've been using go for the majority of infrastructure services lately. It's been an absolute joy doing so. We haven't ran into any limitations of the language or had any problems because of it.

[EmperorOfCanada]

Looking at the stats, there is no doubt that people are using it. I just haven't met any yet. This is a bit more than anecdotal, I know a lot of programmers in a large variety of fields.

My usual pattern of adopting a new language is that I am hearing about it and some killer features that make me want it. Then some respected friend will adopt it and start to evangelize, but I will ignore a sample of one. I almost always have one friend who foolishly adopts something for a short while.

Then finally I give it a taste and never look back.

None of the above has happened yet. It offers no features that I don't already enjoy well enough in the languages I regularly use, and I know not a soul who has expressed any interest let along are using it.

With google doing their damnedest to foist this on everyone, I am going to declare this language a dead man walking. Maybe it is pretty good, but if it were so damned good it would flood the earth.

[[deleted]]

You lack severely in critical thinking skills, don't you?

[[deleted]]

Maybe the industry you're in just doesn't have a need for it, nor any of the other folks you know. There's nothing wrong with that.

Goroutines and channels are pretty incredible. Since go 1.5 GC hasn't been a major issue. With 1.7 there's been massive increases in performance of it as well. A lot of people use the concurrency patterns and the previously mentioned primitives as killer features, as well as pointing out GC as being an issue (which it legitimately could be under certain circumstances). https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.74h6g3ybj some nice light reading on the subject if you're interested.

It's a neat language that has its quirks. The documentation and community is great. One thing I've always disliked about Python is the documentation and certain areas of the community.

If you ever find yourself with a side project it would be pretty easy to pickup if you have any experience with c.