44 ms·

Why we switched from Python to Go

380 points by tortilla 9y ago

carlisle_ 9y ago
> 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.
- tomohawk 9y ago
  This has been a massive win for us vs languages that require you to haul around a runtime and other dependencies.
- camus2 9y ago
  > Go also doesn't have the problem of conflicting system level packages. Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others. > Go doesn't have to deal with interpreter dependencies As long as Go is forward compatible this will old true, but I don't think this was the point of the comment. 'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool. There is a reason why some gophers are working on an actual package manager...
  - ChickeNES 9y ago
    >There is a reason why some gophers are working on an actual package manager... Finally! I had to deal with a golang project once, the dependency management made me want to pull my hair out after using Bundler and Cargo
    - ajmurmann 9y ago
      Yes! Once you've used Bundler and Cargo anything else seems just silly and unacceptable.
  - regecks 9y ago
    > Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others. Not even then, to be honest. I wrote a product that is deployed on many thousands of servers, and all of a sudden a not-insignificant population just started experiencing SIGABRTs on process start. Turns out Amazon Linux (and some others) had removed a syscall that i386 Go on Linux was relying on (https://github.com/golang/go/issues/14795 https://github.com/golang/go/issues/14795). We built our product with a manual patch against "src/runtime/sys_linux_386.s" for many months as a result, and it was really a huge headache to help all our customers. I would be surprised if Python or even Java broke in this way, for example. I was really surprised it even happened in Go to be honest. There are other runtime problems too, we had a weird interaction with a "cloud OS" based on cgroups (CloudLinux) screwing up our Go processes depending on how many goroutines we ran ... I think Go is fantastic but its runtime can definitely clash with its environment ... it's not the same as a C program.
    - pmilot 9y ago
      Was the system call part of POSIX or the standard Linux interface? Because if so, that sounds like the fault belongs to Amazon, not Go. The same thing could happen to the Python interpreter.
- disconnected 9y ago
  > conflicting system level packages In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages. If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.
  - foota 9y ago
    Solved as long as there aren't native dependencies not managed by pip, which there often are.
    - joshuamorton 9y ago
      Wheels solved this problem in 2013. For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels. This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and even qt integration in that pipeline, all isolated. It won't be maximally performant (ie for massive training), but for that you'd want distributed docker deploys or similar anyway.
      - sethammons 9y ago
        Wheels just broke something in our build pipeline. They removed support for Python 2.6 and started tossing errors. I was able to fix it by pinning Wheel which probably should have been done originally by who ever made the build utility, but it would have been a non issue with Go and a binary.
        joshuamorton 9y ago
        Well, python 2.6 was also EoL'd 4 years ago, so yes, if you're using a no longer supported piece of software and not pinning your versions, I'd argue that you're inviting issues.
- tootie 9y ago
  Just use Java.
dundercoder 9y ago
Python 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.
- tschellenbach 9y ago
  I never heard of Nim, something to try out at some point. What's your favorite Nim tutorial?
  - btym 9y ago
    Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable. [0]: https://nim-by-example.github.io https://nim-by-example.github.io [1]: http://howistart.org/posts/nim/1/ http://howistart.org/posts/nim/1/ [2]: https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html
- charred_toast 9y ago
  Can you elaborate, somewhat? How long ago did you try GO? Also, I agree, having a generous assortment of contributed libraries makes all the difference.
- btym 9y ago
  Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.
- jamiesonbecker 9y ago
  Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.
omegaworks 9y ago
>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.
- drdaeman 9y ago
  It's not just metaprogramming, it's a lack of standard types (like sets) paired with a lack of parametric polymorphism cough yeah, generics cough that makes writing some data structure manipulations feel sort of counter-productive. Go makes up for this by making other stuff being easy and fast to code.
- dvt 9y ago
  I'm happy that Python's metaprogramming came in handy for you and your team, but Python's propensity for DSLs is one of the reasons I loathe it so much. I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug.
  - camus2 9y ago
    > I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug. What do you think struct-tags are? it's not like Go is free of DSL either. In fact the std lib itself uses them. Let's not pretend Go is without fault on that matter.
catnaroek 9y ago
> 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?
- acidus 9y ago
  You know there are but that's the end - still not easy to reason about them haha!
- squiguy7 9y ago
  It can be a bear to try and track down some race conditions but at least it will not report false positives. However, it will not catch all race conditions or data races you may have.
  - catnaroek 9y ago
    Is Go even memory-safe in the presence of data races? Don't get me wrong, “memory safety” isn't a hard requirement in my book, but “memory safety or a formal semantics” is.
    - cdoxsey 9y ago
      If you're curious, the behavior is well defined: golang.org/ref/mem
      - catnaroek 9y ago
        My English reading comprehension is admittedly poor, but I don't see any portion of the text that automatically implies that unsynchronized reads and writes are atomic.
pryelluw 9y ago
Re: 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.
- takeda 9y ago
  You could say that nearly for any language. Very often you could do just fine without one.
- pjmlp 9y ago
  That applies to all languages with exception of C, because they didn't want to standardize it as part of the language, hence we got ANSI C + POSIX instead.
  - simias 9y ago
    Don't forget Javascript which is ridiculously under-featured natively. At least C has the excuse of having to run on the bare metal of a wide range of architectures.
    - deleted 9y ago
      [deleted]
  - pryelluw 9y ago
    Go provides built in functionality to develop web applications. Things like template rendering, routing, a generic SQL interface, etc. Which are libraries not commonly found on most languages. Python, OTOH, requires libraries like Flask, Jinja2, and SQLAlchemy to provide the same functionality Go provides as defaults. Thats my whole point.
    - bpicolo 9y ago
      And they're somewhat awkward versions of all the above such that most projects pull in deps like gorilla/* for those things anyway. PHP has template rendering, routing, and database conns built right in too ;)
pmattos 9y ago
A 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 ;)
- sametmax 9y ago
  You have type checks in python if you want them. It's just opt in.
andrewgodwin 9y ago
I 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.
- tschellenbach 9y ago
  Yeah there are some use cases where Python is a clear winner. For us Python seemed like a good fit initially. Traffic was low and the API didn't provide more advanced features where Python's speed becomes an issue. (Ranking, aggregation)
jancsika 9y ago
> Our largest micro service written in Go currently takes 6 seconds to compile. What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?
- kevinconaway 9y ago
  Two large projects that I know of are CockroachDB and Influxdb A quick glance seems to indicate that cockroachdb takes about 9 minutes [1] and infuxdb about 15 minutes [2] [1] https://teamcity.cockroachdb.com/viewLog.html?buildId=380603&tab=buildResultsDiv&buildTypeId=Cockroach_MergeToMaster https://teamcity.cockroachdb.com/viewLog.html?buildId=380603... [2] https://circleci.com/gh/influxdata/influxdb/tree/master https://circleci.com/gh/influxdata/influxdb/tree/master
  - teraflop 9y ago
    That build log for CockroachDB takes a lot longer than a normal build, because it's generating releasable artifacts for multiple platforms, which means running the entire build process multiple times. Also, the build time is dominated by a few vendored C++ dependencies (mainly libprotobuf and libsnappy) which are built using CMake. On my system, building just the Go code for the latest version of CockroachDB (about 360kloc) takes 24 seconds.
- btym 9y ago
  Docker takes about 10m to build: https://jenkins.dockerproject.org/job/docker/job/docker.github.io/job/master/1606/ https://jenkins.dockerproject.org/job/docker/job/docker.gith... Kubernetes takes about 16m: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-bazel-build/223299/ https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/...
  - takeda 9y ago
    Doesn't sound too fast, that's about how long it takes for FreeBSD kernel to be compiled[1] and I would imagine a kernel is more complex. The whole system takes about 50 minutes[2] [1] https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/buildTimeTrend https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/buildTime... [2] https://ci.freebsd.org/job/FreeBSD-head-amd64-build/buildTimeTrend https://ci.freebsd.org/job/FreeBSD-head-amd64-build/buildTim...
servbot 9y ago
Thank you for the insights on Go and how Go has added value to your organizations and enabled a better environment for development at your organization! I love hearing viewpoints on tradeoffs and general evaluations on value of new(ish) development technologies. I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool for me. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem. Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem. I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't. Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C. I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!
- catnaroek 9y ago
  > I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat. > I am hoping Go delivers a bulletproof abstraction for concurrency. Don't hold your breath. Go has always been and will always be about “good enough”, not “bulletproof”.
charred_toast 9y ago
You had me at 4. I'm definitely GOing to give this language a GO now. That was a GOod introduction to the language, a veritable advertisement, if you will.
- charred_toast 9y ago
  The audience on Hacker News takes themselves way too seriously, apparently.
  - charred_toast 9y ago
    Case in point. Thanks. Also, the moderators seem to have no life. Please deactivate my account if you're offended. I'd prefer not to spend more time attempting to communicate with one dimensional, armchair experts.
tschellenbach 9y ago
Author here. Super cool to see this post on HNews. For those of you working with Go. One of the guys on our team wrote a little tool called VirtualGo. It's pretty handy when you're working on multiple go based projects (https://github.com/getstream/vg https://github.com/getstream/vg)
- skj 9y ago
  You might also enjoy wgo: https://github.com/skelterjohn/wgo https://github.com/skelterjohn/wgo (I am skelterjohn)
- aeriklawson 9y ago
  Thank god something like this exists. I gagged at the workspace structure when I first started Go - it gave me enough pain starting out one weekend that my interest faded away. I've been looking for a reason to try it out again and a bunch of comments here got me really excited again.
mjevans 9y ago
The only thing actually missing from Go's standard library that I've wanted is an abstraction of 'native' UI things (assuming you're compiling for a graphical platform). For portability there is shipping your a widget set (QT is OK for this if your licencing needs are compatible with either case).
setheron 9y ago
How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity". Let me give a specific example where moving to Go really helped our tooling: Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when an operator has already ssh'd within the region (the tool is installed on hosts as well -- so that long running tasks can be performed). It was easy to create HTTP clients that easily tunnel through an SSH connection via Go's Dialer interface (present in the net & ssh package) or just directly if no tunnel was needed.
- tschellenbach 9y ago
  Actually moving to Go was a very thorough and long process. We did small example projects and tried out many of the libraries we needed. The blogpost is more of a high level summary of why Go is such a great language.
  - trustfundbaby 9y ago
    I thought it was very thoughtful, detailed, well written and touched on all the points I would need to make a similar decision if it ever came down to it. Thanks for writing it.
  - d23 9y ago
    Oh hey, it's you. I weirdly recognize your name from many many years ago. I have vague memories of dealing with you in submitting an open source patch for Django Facebook. Or maybe it was just a documentation change. Either way I remember you being very polite and professional. Just wanted to say that stuck with me and please keep it up, as I can see you're doing here!
  - VintageCool 9y ago
    Did the Go implementation of the ranked feed use the algorithm optimizations discovered while optimizing the Python implementation?
BLanen 9y ago
A thing that REALLY turned me off in go... The fact that go's Math functions only work with floats. Idiotic. You have so many packages that have to add the same freaking min(int a, int b) function.
- tschellenbach 9y ago
  That is indeed quite weird
- ryanpepper 9y ago
  Does Go have templating?
  - closeparen 9y ago
    Nope! And that's most people's main problem with it.
    - mmargerum 9y ago
      Wrong. Go has templating.
      - baq 9y ago
        yeah, maybe, if what you want is to fill some strings in a template and not to create a type that's generic over other types.
  - mmargerum 9y ago
    Templating is built right into the Stdlib https://golang.org/pkg/text/template/ https://golang.org/pkg/text/template/ The only 3rd party library I pull in to build web servers is gorilla (routing, sessions) and a database driver . Everything else you need is in the go standard library .
    - vgbm 9y ago
      I believe the parent means templating in the sense of generic types: https://en.wikipedia.org/wiki/Template_(C%2B%2B) https://en.wikipedia.org/wiki/Template_(C%2B%2B).
crimsonalucard 9y ago
The guy didn't even mention type checking. Guess it's not a big deal to him. Zero type errors during runtime is a big deal.
- hawkice 9y ago
  Well, it's Go, so you're going to have some runtime type errors. interface{} is way too common to avoid them completely (I had the order of arguments for two ConcurrentMaps wrong, for instance, and it blew up on reads -- found it almost instantly, but alas, at runtime). But it should be a much smaller number than python.
- mmirate 9y ago
  That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What is (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.
  - crimsonalucard 9y ago
    Rust is descended from ml? Isn't Rust a algol based language? Is it functional?
    - FreeFull 9y ago
      OCaml was a really strong influence on Rust. The first Rust compiler was written in OCaml. Rust's traits are also similar to Haskell's typeclasses.
      - mmirate 9y ago
        Rust also has discriminated unions, structural pattern matching and local type inference.
    - mmirate 9y ago
      In addition to typeclasses, Rust has discriminated unions (ergo algebraic datatypes), structural pattern matching, first-class functions, local type inference, and an exclusive/nonexclusive dichotomy of references which serves as a useful proxy for mutability.
wruza 9y ago
>Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on. I’m not criticizing Go since I have no LoC in it, but in other restricted-and-flat languages and areas our company’s expertise quickly (read: in half a decade) went to the limit with no chance to turn the lang partly into dsl and level up. It is like playing rpg where you stuck to level 5 and never get powerful enough to take middle-level quest even with a great party. While it seems cool to have automatic jsonification, build process and out of box concurrency, inability to create something that only your team can use and understand effectively means you’re locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition. This may play a bad game with your future, should roads cross with one who has. Again, the type I’m talking about must be rare, and “there is only one opinionated way to do it” seems to fit better on average tasks.
- twic 9y ago
  > inability to create something that only your team can use and understand effectively means you’re locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition Could you unpack that a bit further? By "inability to create something that only your team can use and understand effectively", do you mean "inability to create something really powerful"? As it stands, it sounds like a good thing.
- rockostrich 9y ago
  I understand what you mean by "inability to create something that only your team can use and understand", but the article doesn't say anything about that and isn't really addressing developing new code in Go. The article is about Python not matching their needs after a few tries at optimization and Go having a similar development time (although if the code was already implemented in Python then I assume the Go code was almost trivial to write so I'm not sure that was a valid point). As for "'there is only one opinionated way to do it' seems to fit better on average tasks", from the Zen of 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." And Python has been used to do plenty of above average tasks.
hprotagonist 9y ago
when you list as a con "package management", meaning "go is even worse than python"... man.
slackingoff2017 9y ago
Why does anyone write web apps in Python? PHP? Ruby? Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own. All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit. Java has come a long way since J2EE. These days it's asynchronous, non-blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.
- sidlls 9y ago
  High quality Java and Go developers are more expensive than Ruby and JS webdevs, partly because there are just so many of the latter.
  - slackingoff2017 9y ago
    Java and Go are much harder to learn. Much more complex from a language perspective, more complicated build process, bigger standard libraries. This leads to a lot of "first languages" being the latter and a perpetual glut of recent grads that know nothing else so will do those jobs for less
- adambard 9y ago
  The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application. My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and build up some CRUD pages in no time flat, and then once you've got enough traffic to care, move parts of the application to more performant platforms (Go/JVM usually) as necessary.
sitkack 9y ago
If you can switch from Python to Go, you weren't using Python anyways, you were use Gothon or Javthon. If you want static binaries, great tooling and an excellent imperative and functional language, try F# with mkbundle. The compelling reasons to use go are shrinking.
- mlevental 9y ago
  one problem: windows
  - sitkack 9y ago
    F# runs everywhere. I dev on OSX using Rider and VS Code. Deploy to Linux. http://fsharp.org/use/linux/ http://fsharp.org/use/linux/ http://fsharp.org/ http://fsharp.org/ > F# runs on Linux, Mac OS X, Android, iOS, Windows, GPUs, and browsers. It is free to use and is open source under an OSI-approved license.
  - lmm 9y ago
    Scala or OCaml are similar options if you don't want to use the CLR.
- mmirate 9y ago
  One problem: CLR interop means that F#, an ML descendant, is usually reduced to "C# but the syntax is less noisy/annoying".
- Scramblejams 9y ago
  Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.
  - dualogy 9y ago
    I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing PureScript compiler once PR #3117 gets accepted). Watch http://github.com/metaleap/gonad/ http://github.com/metaleap/gonad/ --- hoping to "get there" within 2 weeks. Taking unreasonably long already, given that purs already does its jobs on its own like parsing, type-checking, transforming-ML-to-imperative. One reason I'm taking a bit longer than the quickest-dirtiest approach would, I want to preserve the type information as much as possible rather than have all functions accepting and returning and passing `interface{}`s in a JS-like manner. Ie it's meant to generate sane readable human-like idiomatic Go code. Type-classes mapped to interface types, etc. Will also have to attack the need to have any Go package be represented readily on the PureScript side as an existing module that'll show up in auto-complete and pass compilation, so to quickly auto-generate some kind of dummy FFI bindings whenever a Go-land dep is imported and used. Fun ride! There's clearly value in combining Go's compilation speeds, stdlib functionality, rich ecosystem, lean fast binaries, GC etc with a rich and cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and compressed idioms). Will be great for clear thinking and expressive high-level type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha), without having to wrestle with GHC/cabal/stack build annoyances/times and Haskell's whacky academic overly-PhD-ish "wrappings" around raw straightforward real-world needs such as http-server and db-client, where again the Go ecosystem shines.
luord 9y ago
Oh, terrific, another one. The only solid reason this article gave was the second one and, really, is the only one that would ever make sense: If the language one's using becomes the bottleneck then, by all means, change it[1]. Everything else is fluff and opinions. Every single other reason is stuff that is entirely subjective and/or python already has and even the article itself acknowledges, at least for one "reason", python as the better option. Well, at least they tried to be impartial by mentioning the absolutely odious error handling in Go. It's the biggest reason I became so disillusioned with the language once I actually tried it. [1]: I, however, would try switching CPython for pypy before rewriting the entire architecture from scratch. It's more performant.
- eadmund 9y ago
  I don't think that performance is the key reason to switch from Python to Go (although it is nice): as someone who switched from Python to Go, what really made it worthwhile for me was knowing that my code is significantly more likely to be correct when it runs. Go's typing is much nicer than Python's, for this use case. Performance is just gravy.
  - weberc2 9y ago
    I hear that. I work in Python, but prototype most things in Go, simply because many classes of problems benefit from the additional structure, and a compiler that can reason about that structure. Also Go has excellent tooling, it has great libraries, it compiles to static binaries, and anyone can read it. I'm hopeful about Python's type checking though, but so far it leaves a lot to be desired (absolutely no recursive types, lots of bugs, strange restrictions, confusing for variables, etc).
  - thesmallestcat 9y ago
    Type errors/misuses aren't my biggest problem and Go's type system isn't very powerful. The Python code is smaller, more expressive, easier to review, etc. I have more confidence in the correctness of pylinted Python code. I wouldn't jump to trade conciseness for compile-time type safety, particularly for applications, because it's easier to create/not see a logic error in heavy code. And depending on what you're doing, Python's type system may be more powerful/appropriate.
hasenj 9y ago
I think there's a great value in code being straight forward and simple and that is very much not appreciated among many programmers. A good language enables you to "compress" your code without making the code flow impossible to follow. A bad language encourages you to obfuscate the flow of the program using wacky abstraction techniques. Go doesn't exactly hit the sweet spot for semantic compression due to lack of compile time programming (aka generics?), but it does a good job of making the flow of the program pretty clear.
- millstone 9y ago
  IMO Go has poor primitives that make even straightforward code needlessly complicated. Slices are probably the worst. Compare Python's way to inserting a value into a list: a.insert(i, x) With the way that the Go docs suggest: a = append(a[:i], append([]T{x}, a[i:]...)...) Sorting and for-range loops are other examples.
  - tapirl 9y ago
    I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.
    - dingo_bat 9y ago
      WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.
      - tapirl 9y ago
        The insertion operation on slices is expensive and is not recommended to be used frequently. If you use it frequently, please rethink and redesign your data structure, for example, use a list instead.
      - hasenj 9y ago
drej 9y ago
Instead of all the 'we replaced x with y', I'd like to for once read something along the lines of 'we started using x and y side by side, embracing the benefits of each' I use both Python and Go regularly and the use cases rarely overlap. They are both fantastic languages and once you realise what you want to use each one for, you'll be one happy developer. (Applies to many other combinations of languages.)
qaq 9y ago
IF you like Python but need performant compiled alternative take a look at nim.
yeukhon 9y ago
> Python allows you to get pretty creative with the code you’re writing. For instance, you can: > Use MetaClasses to self-register classes upon code initialization Avoid metaclasses.... > Swap out True and False Not possible anymore > Add functions to the list of built-in functions What are the practical reasons? > Overload operators via magic methods Useful but also recommend don’t. I can see someone writting numpy would do that, but most applications don’t have a reason Profile profile profile! Find the bottlenecks.
- tschellenbach 9y ago
  Django uses metaclasses quite nicely actually for the the Forms and Model definitions.
- yen223 9y ago
  "Avoid metaclasses...." Good luck finding a Python library that doesn't use metaclasses anywhere!
  - mrgriffin 9y ago
    How about Requests? https://github.com/requests/requests/search?utf8=%E2%9C%93&q=metaclass&type= https://github.com/requests/requests/search?utf8=%E2%9C%93&q...
it 9y ago
I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail. Go encourages putting the effort into this up front. It pays off later when things go wrong and you want to know why.
- tyingq 9y ago
  Probably complaining from someone used to exceptions and/or assertions, where there is perhaps less boilerplate and manual verification that context bubbles to the right place. You can get there either way, but what you're used to weighs heavily. For your example, depending on my experience, knowing that 1!=2 in some code I'm using directly might be more meaningful or actionable than "out of filehandles for accept()" in some deep chain of dependencies I know little about. Just depends on what you're used to.
  - deleted 9y ago
    [deleted]
  - curun1r 9y ago
    Or anyone who's used a language where errors aren't as stringly-typed as Go and where the compiler can enforce error handling. Exceptions have benefits and drawbacks, but any language that can return a Result type will have better error handling than Go in basically every way.
    - pritambaral 9y ago
      In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.
deleted 9y ago
[deleted]
neilwilson 9y ago
You can tell a lightweight article when you read that all you need to do to get concurrency working is stick 'go' in front of a function call. I must mention that to the LVM developers dealing with my latest lost wakeup problem.
deleted 9y ago
[deleted]
pjmlp 9y ago
Right now, Docker, K8s and their adoption among Microsoft, Oracle, IBM are what keeps me keeping up with what goes on Go, because "hey we need to write some stuff in Go here". For me Reason 3 is exactly the opposite, if I have to spend time manually writing code that other languages give me for free, I am anything but productive.
StreamBright 9y ago
I like these "Why we switched from X to Y" articles. I can be summarized in one sentence most of the time. "Because it supported our use case better."
seunosewa 9y ago
> Go’s fast compile times are a major productivity win compared to languages like Java and C++ which are famous for sluggish compilation speed. C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it’s a simple language.
- raverbashing 9y ago
  Java is not a simple language, period Now, if you mean "simple" as in, needs an IDE to figure out what other languages figure out in runtime/compile time automatically, then yes, it's a dumb language Not to mention the library, which is a jigsaw puzzle composed of barely fitting parts that need to be connected in non-obvious ways to work and made by people who want to prove they know several design patterns and can apply then to any situation instead of something that's rational and straightforward
- tapirl 9y ago
  Neither is java a simple language, nor does Java code compile quickly, in my experience. However the largest disadvantage of Java is Java programs generally consume more than 10x more memory than the same scale Go programs, and need 20x more time to fully to warm up. I do admit Java is more consistent than Go from the syntax design view.
ojhughes 9y ago
Performance shouldn't be a compelling reason to change the language for a project. If they have truly benchmarked, profiled, reworked hotspots using Cython and looked into major bottlenecks such as IO and Python still isn't performing up to scratch then fair enough.
ollieco 9y ago
I've done a fair bit of web dev work in Python but I am currently building my startup (https://www.growthmetrics.io https://www.growthmetrics.io) in Go. It is in the initial stages, but so far it has been pretty good - both as a learning experience and from a developer productivity perspective. I've also open sourced a web app boilerplate that I extracted from GrowthMetrics' codebase - https://github.com/olliecoleman/alloy https://github.com/olliecoleman/alloy. It might be useful for people looking to get started with Go.
TeeWEE 9y ago
I cant help to feel that in Go performance is more important that developer productity. Go is the new C. The code looks a bit clunky, with lots of error checks. I rather work in a language like Python or Kotlin where the code just looks like how you would think the code would like (if i would write it in pseudocode on paper) However Go in big teams will really be nice. Thats why they invented it in the first place.
yedpodtrzitko 9y ago
We are switching from Python to Go, because: > Reason 7 – Strong Ecosystem > Go’s ecosystem (...) it’s of course not as good as (...) Python. Then why do you put that as a reason to switch?
- Liquid_Fire 9y ago
  Similarly, > Reason 5 – Fast Compile Time
kanishkdudeja 9y ago
Here is a similar piece if someone is interested: https://hackernoon.com/the-beauty-of-go-98057e3f0a7d https://hackernoon.com/the-beauty-of-go-98057e3f0a7d
Dowwie 9y ago
Wait just one minute, Thierry... Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python. You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've had on your own but rather did so with the help of the worldwide community of Pythonistas who answer questions and help to solve problems. It takes a village to raise a startup. Don't try to burn the village down after you've grown up and can afford to explore other villages.
- JelteF 9y ago
  Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself. However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.
  - 3pt14159 9y ago
    Hey Jelte, quick question: Did you guys try Numba or Cython? Or did you guys figure that the language simplification that Go provides would be worth it even if the performance considerations were similar?
    - JelteF 9y ago
      No, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us. Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite made us consider switching languages. Eventually we chose to rewrite our whole API codebase in Go for all the reasons in the article. (we did a small trial project in go first to evaluate it)
dingo_bat 9y ago
I'm surprised to see that people choose anything other than C++ if they care about performance. Are you really trying to profile and optimise python and go? It will never be worth it! Just write the same thing in good modern C++ and you get an automatic 100x speed up for most cases. Then optimise to reach the absolute limits of the hardware. Python and go it seems!
- criddell 9y ago
  Some people choose Go rather than C++ for the same reason you went with C++ rather than an assembly language. Most of the time, things only need to be fast enough and trading speed for ease of development, deployment, and maintenance is an easy decision to make.
radiowave 9y ago
"Plan to throw one away. You will, anyhow." - Fred Brooks
atilaneves 9y ago
Since when is Java famous for sluggish compilation???
gbersac 9y ago
Did you consider scala ? I use it at work, and it is awesome. It has awesome error handling (Either/Option >>> exception) on my opinion, a much stronger type system (many errors are checked at compile). It is harder to learn, but you also have top notch package manager with the even bigger scala + java ecosystem.
matt_wulfeck 9y ago
> Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on. I think all new language design must incorporate this goal going forward. It’s been simply too valuable. When I see something introduced that does x, y incrementally better but makes no effort for the above goal I get sad and move on. It’s easy to get caught up in the technical challenges of a language, but this meta challenge is what really helped move the ball forward with Go, and I’d love to see it introduced as a first-class goal in new language design.
- athenot 9y ago
  I think it depends on the use case. For individual component programming, sure: pick a hammer and make everyone use it. But for systems programming, being able to be multi-paradigm is a huge benefit. TIMTOWTDI ;)
- _pmf_ 9y ago
  Some people insist on being obtuse (coincidentally, I'm looking in the general direction of a template heavy C++ user), and for worse or better, personal preference is a large factor in language adoption as opposed to what works best for the industry as an engineering practice.
k_bx 9y ago
The post never mentions PyPy. Have you tried it? Could increase the performance dramatically for free.
apple4ever 9y ago
It has func and var compiler hints, which I hate (just like in Swift). Its harder to read too (just like Swift). I'll stick with Python.

380 points by tortilla 9y ago

> 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.

tomohawk 9y ago
This has been a massive win for us vs languages that require you to haul around a runtime and other dependencies.
camus2 9y ago
> Go also doesn't have the problem of conflicting system level packages. Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others. > Go doesn't have to deal with interpreter dependencies As long as Go is forward compatible this will old true, but I don't think this was the point of the comment. 'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool. There is a reason why some gophers are working on an actual package manager...
- ChickeNES 9y ago
  >There is a reason why some gophers are working on an actual package manager... Finally! I had to deal with a golang project once, the dependency management made me want to pull my hair out after using Bundler and Cargo
  - ajmurmann 9y ago
    Yes! Once you've used Bundler and Cargo anything else seems just silly and unacceptable.
- regecks 9y ago
  > Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others. Not even then, to be honest. I wrote a product that is deployed on many thousands of servers, and all of a sudden a not-insignificant population just started experiencing SIGABRTs on process start. Turns out Amazon Linux (and some others) had removed a syscall that i386 Go on Linux was relying on (https://github.com/golang/go/issues/14795 https://github.com/golang/go/issues/14795). We built our product with a manual patch against "src/runtime/sys_linux_386.s" for many months as a result, and it was really a huge headache to help all our customers. I would be surprised if Python or even Java broke in this way, for example. I was really surprised it even happened in Go to be honest. There are other runtime problems too, we had a weird interaction with a "cloud OS" based on cgroups (CloudLinux) screwing up our Go processes depending on how many goroutines we ran ... I think Go is fantastic but its runtime can definitely clash with its environment ... it's not the same as a C program.
  - pmilot 9y ago
    Was the system call part of POSIX or the standard Linux interface? Because if so, that sounds like the fault belongs to Amazon, not Go. The same thing could happen to the Python interpreter.
disconnected 9y ago
> conflicting system level packages In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages. If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.
- foota 9y ago
  Solved as long as there aren't native dependencies not managed by pip, which there often are.
  - joshuamorton 9y ago
    Wheels solved this problem in 2013. For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels. This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and even qt integration in that pipeline, all isolated. It won't be maximally performant (ie for massive training), but for that you'd want distributed docker deploys or similar anyway.
    - sethammons 9y ago
      Wheels just broke something in our build pipeline. They removed support for Python 2.6 and started tossing errors. I was able to fix it by pinning Wheel which probably should have been done originally by who ever made the build utility, but it would have been a non issue with Go and a binary.
      - joshuamorton 9y ago
        Well, python 2.6 was also EoL'd 4 years ago, so yes, if you're using a no longer supported piece of software and not pinning your versions, I'd argue that you're inviting issues.
tootie 9y ago
Just use Java.

dundercoder 9y ago

Python 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.

tschellenbach 9y ago
I never heard of Nim, something to try out at some point. What's your favorite Nim tutorial?
- btym 9y ago
  Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable. [0]: https://nim-by-example.github.io https://nim-by-example.github.io [1]: http://howistart.org/posts/nim/1/ http://howistart.org/posts/nim/1/ [2]: https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html
charred_toast 9y ago
Can you elaborate, somewhat? How long ago did you try GO? Also, I agree, having a generous assortment of contributed libraries makes all the difference.
btym 9y ago
Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.
jamiesonbecker 9y ago
Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.

omegaworks 9y ago

>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.

drdaeman 9y ago
It's not just metaprogramming, it's a lack of standard types (like sets) paired with a lack of parametric polymorphism cough yeah, generics cough that makes writing some data structure manipulations feel sort of counter-productive. Go makes up for this by making other stuff being easy and fast to code.
dvt 9y ago
I'm happy that Python's metaprogramming came in handy for you and your team, but Python's propensity for DSLs is one of the reasons I loathe it so much. I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug.
- camus2 9y ago
  > I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug. What do you think struct-tags are? it's not like Go is free of DSL either. In fact the std lib itself uses them. Let's not pretend Go is without fault on that matter.

catnaroek 9y ago

> 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?

acidus 9y ago
You know there are but that's the end - still not easy to reason about them haha!
squiguy7 9y ago
It can be a bear to try and track down some race conditions but at least it will not report false positives. However, it will not catch all race conditions or data races you may have.
- catnaroek 9y ago
  Is Go even memory-safe in the presence of data races? Don't get me wrong, “memory safety” isn't a hard requirement in my book, but “memory safety or a formal semantics” is.
  - cdoxsey 9y ago
    If you're curious, the behavior is well defined: golang.org/ref/mem
    - catnaroek 9y ago
      My English reading comprehension is admittedly poor, but I don't see any portion of the text that automatically implies that unsynchronized reads and writes are atomic.

pryelluw 9y ago

Re: 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.

takeda 9y ago
You could say that nearly for any language. Very often you could do just fine without one.
pjmlp 9y ago
That applies to all languages with exception of C, because they didn't want to standardize it as part of the language, hence we got ANSI C + POSIX instead.
- simias 9y ago
  Don't forget Javascript which is ridiculously under-featured natively. At least C has the excuse of having to run on the bare metal of a wide range of architectures.
  - deleted 9y ago
    [deleted]
- pryelluw 9y ago
  Go provides built in functionality to develop web applications. Things like template rendering, routing, a generic SQL interface, etc. Which are libraries not commonly found on most languages. Python, OTOH, requires libraries like Flask, Jinja2, and SQLAlchemy to provide the same functionality Go provides as defaults. Thats my whole point.
  - bpicolo 9y ago
    And they're somewhat awkward versions of all the above such that most projects pull in deps like gorilla/* for those things anyway. PHP has template rendering, routing, and database conns built right in too ;)

pmattos 9y ago

A 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 ;)

sametmax 9y ago
You have type checks in python if you want them. It's just opt in.

andrewgodwin 9y ago

I 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.

tschellenbach 9y ago
Yeah there are some use cases where Python is a clear winner. For us Python seemed like a good fit initially. Traffic was low and the API didn't provide more advanced features where Python's speed becomes an issue. (Ranking, aggregation)

jancsika 9y ago

> Our largest micro service written in Go currently takes 6 seconds to compile. What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?

kevinconaway 9y ago
Two large projects that I know of are CockroachDB and Influxdb A quick glance seems to indicate that cockroachdb takes about 9 minutes [1] and infuxdb about 15 minutes [2] [1] https://teamcity.cockroachdb.com/viewLog.html?buildId=380603&tab=buildResultsDiv&buildTypeId=Cockroach_MergeToMaster https://teamcity.cockroachdb.com/viewLog.html?buildId=380603... [2] https://circleci.com/gh/influxdata/influxdb/tree/master https://circleci.com/gh/influxdata/influxdb/tree/master
- teraflop 9y ago
  That build log for CockroachDB takes a lot longer than a normal build, because it's generating releasable artifacts for multiple platforms, which means running the entire build process multiple times. Also, the build time is dominated by a few vendored C++ dependencies (mainly libprotobuf and libsnappy) which are built using CMake. On my system, building just the Go code for the latest version of CockroachDB (about 360kloc) takes 24 seconds.
btym 9y ago
Docker takes about 10m to build: https://jenkins.dockerproject.org/job/docker/job/docker.github.io/job/master/1606/ https://jenkins.dockerproject.org/job/docker/job/docker.gith... Kubernetes takes about 16m: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-bazel-build/223299/ https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/...
- takeda 9y ago
  Doesn't sound too fast, that's about how long it takes for FreeBSD kernel to be compiled[1] and I would imagine a kernel is more complex. The whole system takes about 50 minutes[2] [1] https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/buildTimeTrend https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/buildTime... [2] https://ci.freebsd.org/job/FreeBSD-head-amd64-build/buildTimeTrend https://ci.freebsd.org/job/FreeBSD-head-amd64-build/buildTim...

servbot 9y ago

Thank you for the insights on Go and how Go has added value to your organizations and enabled a better environment for development at your organization! I love hearing viewpoints on tradeoffs and general evaluations on value of new(ish) development technologies. I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool for me. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem. Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem. I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't. Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C. I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!

catnaroek 9y ago
> I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat. > I am hoping Go delivers a bulletproof abstraction for concurrency. Don't hold your breath. Go has always been and will always be about “good enough”, not “bulletproof”.

charred_toast 9y ago

You had me at 4. I'm definitely GOing to give this language a GO now. That was a GOod introduction to the language, a veritable advertisement, if you will.

charred_toast 9y ago
The audience on Hacker News takes themselves way too seriously, apparently.
- charred_toast 9y ago
  Case in point. Thanks. Also, the moderators seem to have no life. Please deactivate my account if you're offended. I'd prefer not to spend more time attempting to communicate with one dimensional, armchair experts.

tschellenbach 9y ago

Author here. Super cool to see this post on HNews. For those of you working with Go. One of the guys on our team wrote a little tool called VirtualGo. It's pretty handy when you're working on multiple go based projects (https://github.com/getstream/vg https://github.com/getstream/vg)

skj 9y ago
You might also enjoy wgo: https://github.com/skelterjohn/wgo https://github.com/skelterjohn/wgo (I am skelterjohn)
aeriklawson 9y ago
Thank god something like this exists. I gagged at the workspace structure when I first started Go - it gave me enough pain starting out one weekend that my interest faded away. I've been looking for a reason to try it out again and a bunch of comments here got me really excited again.

mjevans 9y ago

The only thing actually missing from Go's standard library that I've wanted is an abstraction of 'native' UI things (assuming you're compiling for a graphical platform). For portability there is shipping your a widget set (QT is OK for this if your licencing needs are compatible with either case).

setheron 9y ago

How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity". Let me give a specific example where moving to Go really helped our tooling: Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when an operator has already ssh'd within the region (the tool is installed on hosts as well -- so that long running tasks can be performed). It was easy to create HTTP clients that easily tunnel through an SSH connection via Go's Dialer interface (present in the net & ssh package) or just directly if no tunnel was needed.

tschellenbach 9y ago
Actually moving to Go was a very thorough and long process. We did small example projects and tried out many of the libraries we needed. The blogpost is more of a high level summary of why Go is such a great language.
- trustfundbaby 9y ago
  I thought it was very thoughtful, detailed, well written and touched on all the points I would need to make a similar decision if it ever came down to it. Thanks for writing it.
- d23 9y ago
  Oh hey, it's you. I weirdly recognize your name from many many years ago. I have vague memories of dealing with you in submitting an open source patch for Django Facebook. Or maybe it was just a documentation change. Either way I remember you being very polite and professional. Just wanted to say that stuck with me and please keep it up, as I can see you're doing here!
- VintageCool 9y ago
  Did the Go implementation of the ranked feed use the algorithm optimizations discovered while optimizing the Python implementation?

BLanen 9y ago

A thing that REALLY turned me off in go... The fact that go's Math functions only work with floats. Idiotic. You have so many packages that have to add the same freaking min(int a, int b) function.

tschellenbach 9y ago
That is indeed quite weird
ryanpepper 9y ago
Does Go have templating?
- closeparen 9y ago
  Nope! And that's most people's main problem with it.
  - mmargerum 9y ago
    Wrong. Go has templating.
    - baq 9y ago
      yeah, maybe, if what you want is to fill some strings in a template and not to create a type that's generic over other types.
- mmargerum 9y ago
  Templating is built right into the Stdlib https://golang.org/pkg/text/template/ https://golang.org/pkg/text/template/ The only 3rd party library I pull in to build web servers is gorilla (routing, sessions) and a database driver . Everything else you need is in the go standard library .
  - vgbm 9y ago
    I believe the parent means templating in the sense of generic types: https://en.wikipedia.org/wiki/Template_(C%2B%2B) https://en.wikipedia.org/wiki/Template_(C%2B%2B).

crimsonalucard 9y ago

The guy didn't even mention type checking. Guess it's not a big deal to him. Zero type errors during runtime is a big deal.

hawkice 9y ago
Well, it's Go, so you're going to have some runtime type errors. interface{} is way too common to avoid them completely (I had the order of arguments for two ConcurrentMaps wrong, for instance, and it blew up on reads -- found it almost instantly, but alas, at runtime). But it should be a much smaller number than python.
mmirate 9y ago
That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What is (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.
- crimsonalucard 9y ago
  Rust is descended from ml? Isn't Rust a algol based language? Is it functional?
  - FreeFull 9y ago
    OCaml was a really strong influence on Rust. The first Rust compiler was written in OCaml. Rust's traits are also similar to Haskell's typeclasses.
    - mmirate 9y ago
      Rust also has discriminated unions, structural pattern matching and local type inference.
  - mmirate 9y ago
    In addition to typeclasses, Rust has discriminated unions (ergo algebraic datatypes), structural pattern matching, first-class functions, local type inference, and an exclusive/nonexclusive dichotomy of references which serves as a useful proxy for mutability.

wruza 9y ago

>Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on. I’m not criticizing Go since I have no LoC in it, but in other restricted-and-flat languages and areas our company’s expertise quickly (read: in half a decade) went to the limit with no chance to turn the lang partly into dsl and level up. It is like playing rpg where you stuck to level 5 and never get powerful enough to take middle-level quest even with a great party. While it seems cool to have automatic jsonification, build process and out of box concurrency, inability to create something that only your team can use and understand effectively means you’re locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition. This may play a bad game with your future, should roads cross with one who has. Again, the type I’m talking about must be rare, and “there is only one opinionated way to do it” seems to fit better on average tasks.

twic 9y ago
> inability to create something that only your team can use and understand effectively means you’re locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition Could you unpack that a bit further? By "inability to create something that only your team can use and understand effectively", do you mean "inability to create something really powerful"? As it stands, it sounds like a good thing.
rockostrich 9y ago
I understand what you mean by "inability to create something that only your team can use and understand", but the article doesn't say anything about that and isn't really addressing developing new code in Go. The article is about Python not matching their needs after a few tries at optimization and Go having a similar development time (although if the code was already implemented in Python then I assume the Go code was almost trivial to write so I'm not sure that was a valid point). As for "'there is only one opinionated way to do it' seems to fit better on average tasks", from the Zen of 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." And Python has been used to do plenty of above average tasks.

hprotagonist 9y ago

when you list as a con "package management", meaning "go is even worse than python"... man.

slackingoff2017 9y ago

Why does anyone write web apps in Python? PHP? Ruby? Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own. All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit. Java has come a long way since J2EE. These days it's asynchronous, non-blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.

sidlls 9y ago
High quality Java and Go developers are more expensive than Ruby and JS webdevs, partly because there are just so many of the latter.
- slackingoff2017 9y ago
  Java and Go are much harder to learn. Much more complex from a language perspective, more complicated build process, bigger standard libraries. This leads to a lot of "first languages" being the latter and a perpetual glut of recent grads that know nothing else so will do those jobs for less
adambard 9y ago
The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application. My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and build up some CRUD pages in no time flat, and then once you've got enough traffic to care, move parts of the application to more performant platforms (Go/JVM usually) as necessary.

sitkack 9y ago

If you can switch from Python to Go, you weren't using Python anyways, you were use Gothon or Javthon. If you want static binaries, great tooling and an excellent imperative and functional language, try F# with mkbundle. The compelling reasons to use go are shrinking.

mlevental 9y ago
one problem: windows
- sitkack 9y ago
  F# runs everywhere. I dev on OSX using Rider and VS Code. Deploy to Linux. http://fsharp.org/use/linux/ http://fsharp.org/use/linux/ http://fsharp.org/ http://fsharp.org/ > F# runs on Linux, Mac OS X, Android, iOS, Windows, GPUs, and browsers. It is free to use and is open source under an OSI-approved license.
- lmm 9y ago
  Scala or OCaml are similar options if you don't want to use the CLR.
mmirate 9y ago
One problem: CLR interop means that F#, an ML descendant, is usually reduced to "C# but the syntax is less noisy/annoying".
Scramblejams 9y ago
Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.
- dualogy 9y ago
  I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing PureScript compiler once PR #3117 gets accepted). Watch http://github.com/metaleap/gonad/ http://github.com/metaleap/gonad/ --- hoping to "get there" within 2 weeks. Taking unreasonably long already, given that purs already does its jobs on its own like parsing, type-checking, transforming-ML-to-imperative. One reason I'm taking a bit longer than the quickest-dirtiest approach would, I want to preserve the type information as much as possible rather than have all functions accepting and returning and passing `interface{}`s in a JS-like manner. Ie it's meant to generate sane readable human-like idiomatic Go code. Type-classes mapped to interface types, etc. Will also have to attack the need to have any Go package be represented readily on the PureScript side as an existing module that'll show up in auto-complete and pass compilation, so to quickly auto-generate some kind of dummy FFI bindings whenever a Go-land dep is imported and used. Fun ride! There's clearly value in combining Go's compilation speeds, stdlib functionality, rich ecosystem, lean fast binaries, GC etc with a rich and cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and compressed idioms). Will be great for clear thinking and expressive high-level type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha), without having to wrestle with GHC/cabal/stack build annoyances/times and Haskell's whacky academic overly-PhD-ish "wrappings" around raw straightforward real-world needs such as http-server and db-client, where again the Go ecosystem shines.

luord 9y ago

Oh, terrific, another one. The only solid reason this article gave was the second one and, really, is the only one that would ever make sense: If the language one's using becomes the bottleneck then, by all means, change it[1]. Everything else is fluff and opinions. Every single other reason is stuff that is entirely subjective and/or python already has and even the article itself acknowledges, at least for one "reason", python as the better option. Well, at least they tried to be impartial by mentioning the absolutely odious error handling in Go. It's the biggest reason I became so disillusioned with the language once I actually tried it. [1]: I, however, would try switching CPython for pypy before rewriting the entire architecture from scratch. It's more performant.

eadmund 9y ago
I don't think that performance is the key reason to switch from Python to Go (although it is nice): as someone who switched from Python to Go, what really made it worthwhile for me was knowing that my code is significantly more likely to be correct when it runs. Go's typing is much nicer than Python's, for this use case. Performance is just gravy.
- weberc2 9y ago
  I hear that. I work in Python, but prototype most things in Go, simply because many classes of problems benefit from the additional structure, and a compiler that can reason about that structure. Also Go has excellent tooling, it has great libraries, it compiles to static binaries, and anyone can read it. I'm hopeful about Python's type checking though, but so far it leaves a lot to be desired (absolutely no recursive types, lots of bugs, strange restrictions, confusing for variables, etc).
- thesmallestcat 9y ago
  Type errors/misuses aren't my biggest problem and Go's type system isn't very powerful. The Python code is smaller, more expressive, easier to review, etc. I have more confidence in the correctness of pylinted Python code. I wouldn't jump to trade conciseness for compile-time type safety, particularly for applications, because it's easier to create/not see a logic error in heavy code. And depending on what you're doing, Python's type system may be more powerful/appropriate.

hasenj 9y ago

I think there's a great value in code being straight forward and simple and that is very much not appreciated among many programmers. A good language enables you to "compress" your code without making the code flow impossible to follow. A bad language encourages you to obfuscate the flow of the program using wacky abstraction techniques. Go doesn't exactly hit the sweet spot for semantic compression due to lack of compile time programming (aka generics?), but it does a good job of making the flow of the program pretty clear.

millstone 9y ago
IMO Go has poor primitives that make even straightforward code needlessly complicated. Slices are probably the worst. Compare Python's way to inserting a value into a list: a.insert(i, x) With the way that the Go docs suggest: a = append(a[:i], append([]T{x}, a[i:]...)...) Sorting and for-range loops are other examples.
- tapirl 9y ago
  I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.
  - dingo_bat 9y ago
    WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.
    - tapirl 9y ago
      The insertion operation on slices is expensive and is not recommended to be used frequently. If you use it frequently, please rethink and redesign your data structure, for example, use a list instead.
    - hasenj 9y ago

drej 9y ago

Instead of all the 'we replaced x with y', I'd like to for once read something along the lines of 'we started using x and y side by side, embracing the benefits of each' I use both Python and Go regularly and the use cases rarely overlap. They are both fantastic languages and once you realise what you want to use each one for, you'll be one happy developer. (Applies to many other combinations of languages.)

qaq 9y ago

IF you like Python but need performant compiled alternative take a look at nim.

yeukhon 9y ago

> Python allows you to get pretty creative with the code you’re writing. For instance, you can: > Use MetaClasses to self-register classes upon code initialization Avoid metaclasses.... > Swap out True and False Not possible anymore > Add functions to the list of built-in functions What are the practical reasons? > Overload operators via magic methods Useful but also recommend don’t. I can see someone writting numpy would do that, but most applications don’t have a reason Profile profile profile! Find the bottlenecks.

tschellenbach 9y ago
Django uses metaclasses quite nicely actually for the the Forms and Model definitions.
yen223 9y ago
"Avoid metaclasses...." Good luck finding a Python library that doesn't use metaclasses anywhere!
- mrgriffin 9y ago
  How about Requests? https://github.com/requests/requests/search?utf8=%E2%9C%93&q=metaclass&type= https://github.com/requests/requests/search?utf8=%E2%9C%93&q...

it 9y ago

I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail. Go encourages putting the effort into this up front. It pays off later when things go wrong and you want to know why.

tyingq 9y ago
Probably complaining from someone used to exceptions and/or assertions, where there is perhaps less boilerplate and manual verification that context bubbles to the right place. You can get there either way, but what you're used to weighs heavily. For your example, depending on my experience, knowing that 1!=2 in some code I'm using directly might be more meaningful or actionable than "out of filehandles for accept()" in some deep chain of dependencies I know little about. Just depends on what you're used to.
- deleted 9y ago
  [deleted]
- curun1r 9y ago
  Or anyone who's used a language where errors aren't as stringly-typed as Go and where the compiler can enforce error handling. Exceptions have benefits and drawbacks, but any language that can return a Result type will have better error handling than Go in basically every way.
  - pritambaral 9y ago
    In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.

deleted 9y ago

[deleted]

neilwilson 9y ago

You can tell a lightweight article when you read that all you need to do to get concurrency working is stick 'go' in front of a function call. I must mention that to the LVM developers dealing with my latest lost wakeup problem.

deleted 9y ago

[deleted]

pjmlp 9y ago

Right now, Docker, K8s and their adoption among Microsoft, Oracle, IBM are what keeps me keeping up with what goes on Go, because "hey we need to write some stuff in Go here". For me Reason 3 is exactly the opposite, if I have to spend time manually writing code that other languages give me for free, I am anything but productive.

StreamBright 9y ago

I like these "Why we switched from X to Y" articles. I can be summarized in one sentence most of the time. "Because it supported our use case better."

seunosewa 9y ago

> Go’s fast compile times are a major productivity win compared to languages like Java and C++ which are famous for sluggish compilation speed. C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it’s a simple language.

raverbashing 9y ago
Java is not a simple language, period Now, if you mean "simple" as in, needs an IDE to figure out what other languages figure out in runtime/compile time automatically, then yes, it's a dumb language Not to mention the library, which is a jigsaw puzzle composed of barely fitting parts that need to be connected in non-obvious ways to work and made by people who want to prove they know several design patterns and can apply then to any situation instead of something that's rational and straightforward
tapirl 9y ago
Neither is java a simple language, nor does Java code compile quickly, in my experience. However the largest disadvantage of Java is Java programs generally consume more than 10x more memory than the same scale Go programs, and need 20x more time to fully to warm up. I do admit Java is more consistent than Go from the syntax design view.

ojhughes 9y ago

Performance shouldn't be a compelling reason to change the language for a project. If they have truly benchmarked, profiled, reworked hotspots using Cython and looked into major bottlenecks such as IO and Python still isn't performing up to scratch then fair enough.

ollieco 9y ago

I've done a fair bit of web dev work in Python but I am currently building my startup (https://www.growthmetrics.io https://www.growthmetrics.io) in Go. It is in the initial stages, but so far it has been pretty good - both as a learning experience and from a developer productivity perspective. I've also open sourced a web app boilerplate that I extracted from GrowthMetrics' codebase - https://github.com/olliecoleman/alloy https://github.com/olliecoleman/alloy. It might be useful for people looking to get started with Go.

TeeWEE 9y ago

I cant help to feel that in Go performance is more important that developer productity. Go is the new C. The code looks a bit clunky, with lots of error checks. I rather work in a language like Python or Kotlin where the code just looks like how you would think the code would like (if i would write it in pseudocode on paper) However Go in big teams will really be nice. Thats why they invented it in the first place.

yedpodtrzitko 9y ago

We are switching from Python to Go, because: > Reason 7 – Strong Ecosystem > Go’s ecosystem (...) it’s of course not as good as (...) Python. Then why do you put that as a reason to switch?

Liquid_Fire 9y ago
Similarly, > Reason 5 – Fast Compile Time

kanishkdudeja 9y ago

Here is a similar piece if someone is interested: https://hackernoon.com/the-beauty-of-go-98057e3f0a7d https://hackernoon.com/the-beauty-of-go-98057e3f0a7d

Dowwie 9y ago

Wait just one minute, Thierry... Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python. You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've had on your own but rather did so with the help of the worldwide community of Pythonistas who answer questions and help to solve problems. It takes a village to raise a startup. Don't try to burn the village down after you've grown up and can afford to explore other villages.

JelteF 9y ago
Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself. However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.
- 3pt14159 9y ago
  Hey Jelte, quick question: Did you guys try Numba or Cython? Or did you guys figure that the language simplification that Go provides would be worth it even if the performance considerations were similar?
  - JelteF 9y ago
    No, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us. Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite made us consider switching languages. Eventually we chose to rewrite our whole API codebase in Go for all the reasons in the article. (we did a small trial project in go first to evaluate it)

dingo_bat 9y ago

I'm surprised to see that people choose anything other than C++ if they care about performance. Are you really trying to profile and optimise python and go? It will never be worth it! Just write the same thing in good modern C++ and you get an automatic 100x speed up for most cases. Then optimise to reach the absolute limits of the hardware. Python and go it seems!

criddell 9y ago
Some people choose Go rather than C++ for the same reason you went with C++ rather than an assembly language. Most of the time, things only need to be fast enough and trading speed for ease of development, deployment, and maintenance is an easy decision to make.

radiowave 9y ago

"Plan to throw one away. You will, anyhow." - Fred Brooks

atilaneves 9y ago

Since when is Java famous for sluggish compilation???

gbersac 9y ago

Did you consider scala ? I use it at work, and it is awesome. It has awesome error handling (Either/Option >>> exception) on my opinion, a much stronger type system (many errors are checked at compile). It is harder to learn, but you also have top notch package manager with the even bigger scala + java ecosystem.

matt_wulfeck 9y ago

> Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on. I think all new language design must incorporate this goal going forward. It’s been simply too valuable. When I see something introduced that does x, y incrementally better but makes no effort for the above goal I get sad and move on. It’s easy to get caught up in the technical challenges of a language, but this meta challenge is what really helped move the ball forward with Go, and I’d love to see it introduced as a first-class goal in new language design.

athenot 9y ago
I think it depends on the use case. For individual component programming, sure: pick a hammer and make everyone use it. But for systems programming, being able to be multi-paradigm is a huge benefit. TIMTOWTDI ;)
_pmf_ 9y ago
Some people insist on being obtuse (coincidentally, I'm looking in the general direction of a template heavy C++ user), and for worse or better, personal preference is a large factor in language adoption as opposed to what works best for the industry as an engineering practice.

k_bx 9y ago

The post never mentions PyPy. Have you tried it? Could increase the performance dramatically for free.

apple4ever 9y ago

It has func and var compiler hints, which I hate (just like in Swift). Its harder to read too (just like Swift). I'll stick with Python.