Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we switched from Python to Go

getstream.io

Post reply on HN
Print view View original

101–110 of 406 posts

Re: Why we switched from Python to Go

#101

Post by joshuamorton »

sethammons wrote: post #98
joshuamorton wrote: post #79

Earlier quoted context omitted.

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 eve…

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.

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.

Re: Why we switched from Python to Go

#102

Post by protomok »

weberc2 wrote: post #89
disconnected wrote: post #33

Earlier quoted context omitted.

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

We use Nix which is much nicer than pyenv/virtual environment, but it's still a pain compared to Go. This is mostly due to Python's runtime model, and maybe also the tendency for Python applications to have very tall, broad dependency graphs. Working with nix is also not very easy; docker might fare better here, but probably just a lateral move. In any case, Go outclasses Python on deployments. Also, my company is lo…

I've been evaluating Cython for both code obfuscation and for using C based extensions to improve performance. Cython is pretty nice, but shipping binary only Python extensions can be such a pain, especially dealing with 2-byte vs 4-byte unicode representation issues.

I need to try Go one of these days !

Re: Why we switched from Python to Go

#103

Post by adwn »

ubernostrum wrote: post #71
slackingoff2017 wrote: post #46

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 faste…

Why does anyone write web apps in Python? PHP? Ruby? First: Because squeezing every last nanosecond's worth of performance out of your web app is actually an extremely rare problem to have. And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly, but I'd bet a lot of money that you don't do that. The typical web application -…

> And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly

The performance gain from Python/Ruby to Java/Go is an order of magnitude larger than the performance gain from Java/Go to assembly. The productivity loss from Python/Ruby to Java/Go is an order of magnitude smaller than the productivity loss from Java/Go to assembly.

Therefore, going from Python/Ruby to Java/Go might be a good idea for web apps, but going from Java/Go to assembly is virtually never a good idea for web apps.

Re: Why we switched from Python to Go

#104

Post by sethammons »

albinofrenchy wrote: post #67
hasenj wrote: post #56

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 co…

I tried using Go this weekend and basically just abandoned it when I learned that it only had 'generic's for three built-in types and other than that you are forced to essentially dynamic cast everywhere. I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.

I venture to say that if you are casting/converting everywhere, you are likely doing it wrong. An interface{} says nothing. It should generally be avoided. However, I do find this to be a pain when working with numbers. Floats and ints mixed up is not fun. Python is so vastly easier to work with in that arena.

Re: Why we switched from Python to Go

#105

Post by jxramos »

it wrote: post #91

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 s…

I've been searching if there's an equivalent in some Python unit test framework for Google test's predicate-formatter feature. Crafting an intelligible failure interpretation that even directs a developer for what to fix is solid gold. https://github.com/google/googletest/blob/master/googletest/...

Re: Why we switched from Python to Go

#106

Post by deathanatos »

it wrote: post #91

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 s…

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

In Python, one would need to supply the message argument to avoid that. But Go seems no different, really; you still have to supply the message. My understanding of the testing package is that Python's:

    self.assertEqual(expect, actual, f'expected ({expect!r} != actual ({actual!r})')
is approximately:

    if expect != actual {
        test.Errorf("expected (%s) != actual (%s)", expect, actual)
    }
I'm honestly not sure which is "better".

I do wish Python could figure out something better than "1 != 2", s.t. the assert would just do The Right Thing™ in a graceful way, but doing so would require facilities the language hasn't got (e.g., some macro capability). There are some packages that do some black magic stack walking to do slightly better, IIRC.

To me, Go's error handling falls a bit short because it is possible to forget to handle an error (though thankfully that unused variables is an error makes this more difficult), and you don't get an error or a result, you always get an error and result. (The language lacks a sum type, so it can't really do much better here.) It's on the programmer to not use the result, and to me that felt and still feels weird. The constant do-something, check, propagate is thing, too … I had hoped C had beat that out of language design as too tedious, frankly. (C.f. Rust, where even though error propagation is always explicit, it was `try!(foo)` early on, and `foo?` more recently.)

Re: Why we switched from Python to Go

#107

Post by curun1r »

tyingq wrote: post #94
it wrote: post #91

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 s…

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()"…

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.

Re: Why we switched from Python to Go

#108

Post by it »

tyingq wrote: post #94
it wrote: post #91

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 s…

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()"…

The point I'm making here is that everyone knows 1!=2. It's not helpful for a test to tell you that because then you have to go hunting around to figure out what is wrong instead of it just giving you at least a rough idea right away. It does not depend on what you're used to.

Re: Why we switched from Python to Go

#110

Post by tyingq »

it wrote: post #108
tyingq wrote: post #94

Earlier quoted context omitted.

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()"…

The point I'm making here is that everyone knows 1!=2. It's not helpful for a test to tell you that because then you have to go hunting around to figure out what is wrong instead of it just giving you at least a rough idea right away. It does not depend on what you're used to.

I get that part. I'm saying Go doesn't fix stupid either. I can panic 6 layers into a dependency chain with a verbose error message that helps nobody.

It's often easier to fix 1!=2 if I know the entire error stack than it is to know exactly what happened where, but not the path down.

Like as obtuse as 1!=2 is, with exceptions, I might more easily recognize it as a reference leak.

Post reply on HN