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

111–120 of 406 posts

Re: Why we switched from Python to Go

#111

Post by hack4supper »

riku_iki wrote: post #70
jaequery wrote: post #64

Earlier quoted context omitted.

well then why go with any of them when erlang and elixir has them all beat in terms of performance AND stability? let alone the power of concurrent processes it can handle that none of those languages can hold a candle to. why? :)

Because your statements are very challengeable. Erlang is much slower in raw performance than both go and jvm: https://benchmarksgame.alioth.debian.org/u64q/erlang.html Async approache similar to Erlang was reproduced for Java and Go already: https://akka.io

hi riku_iki, I just checked out the link akka.io and it says that it caters to java/scala only ... from your last statement I understood that it was meant for java and go.

Re: Why we switched from Python to Go

#112

Post by crimsonalucard »

mmirate wrote: post #92
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.

Rust is descended from ml? Isn't Rust a algol based language? Is it functional?

Re: Why we switched from Python to Go

#113

Post by deathanatos »

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 doesn't completely solve this problem. For example, your example of matplotlib, IIRC, has a dependency on libblas: a C library. This dependency isn't captured in the wheel metadata, and it's up to you to install the right libblas on the host, or somewhere where it will get loaded. (Though honestly, this isn't usually an unmanageable level of complexity. But virtualenvs are not free from external dependencies always.)

IIRC, we also had a problem where a wheel failed to find symbols in a SO it was linked against. It turns out that the wheel worked fine in precise, but failed in trusty, and we ended up having to split our wheel repository because the wheel was specific to the Ubuntu release. (It seemed, at the time, that whatever SO it was linked against appears to have made backwards incompatible changes without changing the major.) There are rare cases like this where the wheel is unique to attributes of the host that the wheel metadata can't capture.

Re: Why we switched from Python to Go

#114

Post by pwang »

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…

Have you actually done this? If so, on what platform(s)?

Re: Why we switched from Python to Go

#115

Post by 0xCMP »

jeffshek wrote: post #95
gruez wrote: post #65

Earlier quoted context omitted.

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.

Can confirm that once upgrading macOS required using Docker to be productive, because some C-dep we had stopped working. We have developers using macOS 10.10 to avoid any issues (although they're likely gone by now, it's not worth the effort to figure it out anymore).

Re: Why we switched from Python to Go

#117

Post by it »

deathanatos wrote: post #106
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} != ac…

I think the if-statement one is clearer, but in terms of results they're both fine. At the same time, I usually don't see people put in the extra work to add these helpful messages to their assertions. Maybe one reason is because they make the code a little harder to read.

Re: Why we switched from Python to Go

#118

Post by yen223 »

yeukhon wrote: post #87

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

"Avoid metaclasses...."

Good luck finding a Python library that doesn't use metaclasses anywhere!

Re: Why we switched from Python to Go

#119

Post by dguaraglia »

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.

Something as simple as allowing the use of multi-result calls in if statements would make a huge difference. Being able to write "if err := blah(); err != nil { ... }" is great (although it does kind of hide the original call.)

Re: Why we switched from Python to Go

#120

Post by Scramblejams »

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.

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.

Post reply on HN