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

91–100 of 406 posts

Re: Why we switched from Python to Go

#91

Post by it »

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.

Re: Why we switched from Python to Go

#92

Post by mmirate »

crimsonalucard wrote: post #38

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.

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.

Re: Why we switched from Python to Go

#93

Post by mmirate »

sitkack wrote: post #47

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.

One problem: CLR interop means that F#, an ML descendant, is usually reduced to "C# but the syntax is less noisy/annoying".

Re: Why we switched from Python to Go

#94

Post by tyingq »

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()" in some deep chain of dependencies I know little about. Just depends on what you're used to.

Re: Why we switched from Python to Go

#95

Post by jeffshek »

gruez wrote: post #65
hasenj wrote: post #48

Earlier quoted context omitted.

> this is solved with virtualenv Except when you run into edge cases, which happens all the time.

elaborate?

Most of the time pip installs work fine, but once a while after some type of OS upgrade (namely, my experience has been MacOS), you run into odd compiler types of issues.

So it's why a lot of teams will use either Vagrant / Docker to setup local developer environments.

Re: Why we switched from Python to Go

#96

Post by [deleted] »

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

[deleted]

Re: Why we switched from Python to Go

#97

Post by piinbinary »

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 think the semantics of Go's error handling is pretty good, but the syntax could use work.

Re: Why we switched from Python to Go

#98

Post by sethammons »

joshuamorton wrote: post #79
foota wrote: post #37

Earlier quoted context omitted.

Solved as long as there aren't native dependencies not managed by pip, which there often are.

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.

Re: Why we switched from Python to Go

#100

Post by knodi »

piinbinary wrote: post #97
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 think the semantics of Go's error handling is pretty good, but the syntax could use work.

Ya my number 1 request for Go2, better syntax for error handling.
Post reply on HN