Live data from Hacker News

Why we switched from Python to Go

getstream.io

191–200 of 406 posts

Re: Why we switched from Python to Go

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

If you want a nice ML with low GC latency, how about Rust?

(Did you look at tuning the GC? As a Scala guy I know a some people write off the JVM because the default GC settings are optimised for throughput rather than latency (whereas Go does the opposite), when often their requirements are comfortably within what the JVM can do when suitably configured. That said I've heard the CLR is less tuneable)

Re: Why we switched from Python to Go

#192
post #118
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!

How about Requests?

https://github.com/requests/requests/search?utf8=%E2%9C%93&q...

Re: Why we switched from Python to Go

#193
post #48

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.

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

Are you using the newer venv package from the stdlib or the old virtualenv package from pypi? I have never encountered a single issue with the former.

Re: Why we switched from Python to Go

#194

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…

Ehem:

https://github.com/squeaky-pl/japronto

https://github.com/channelcat/sanic

Re: Why we switched from Python to Go

#195

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

> For example, your example of matplotlib, IIRC, has a dependency on libblas: a C library

And with the wheel packaging, you're free to embed that library in the wheel that depends on it. You can also not do that and rely on the system libraries. The wheel provides you a way to do what you want, but doesn't force you to do it.

The are good reasons for either of those approaches, so I'd say wheel does solve the issue.

Re: Why we switched from Python to Go

#196

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…

Can you point a clueless (about Java web dev) person to a nice, lightweight framework that's easy to learn and to set up? Please no XML configuration files and other such nonsense. For me as a Python/Rails/C++ dev Java has a reputation of being too large, too complex and otherwise.. unwieldy. Hearing things like "To test a bug I had to start 6 services on my computer and then I ran out of memory (computer had 16GB)"…

The Spark Framework [0] is pretty easy to pick up IMO.

Spring (with Spring Boot) has approachable tutorials [1] on how to get started but will get intimidating pretty fast.

I highly recommend using Kotlin instead of Java when trying out the JVM, though.

[0] http://sparkjava.com/ [1] https://spring.io/guides/gs/rest-service/

Re: Why we switched from Python to Go

#197

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

+1 for Nim: it writes like Python and runs like C.

Re: Why we switched from Python to Go

#198

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

Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at 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.

Would you kindly share you experience on using Nim for that project?

Re: Why we switched from Python to Go

#199
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/...

golang routine

Re: Why we switched from Python to Go

#200
post #165

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…

I was wondering the same thing, and it frustrates me. I think people obviously enjoy using Python/Ruby or whatever for small scripts, and by inductive reasoning they think they can enjoy programming even larger projects in these languages. They also rationalize the slowness by pretending that performance doesn't matter or that the bottle neck is the database. They abuse the adage about "premature optimization" being…

> by pretending that performance doesn't matter or that the bottle neck is the database.

Or, you know... You can actually measure those things. And unless you're growing like crazy, or have a massive initial audience, you're likely to find that 90%+ of the app time is spent in the database and your CPU time isn't even close to maxed out.

Why would you assume people would pretend any of that is true?

Post reply on HN