Live data from Hacker News

Why we switched from Python to Go

getstream.io

151–160 of 406 posts

Re: Why we switched from Python to Go

#151
post #32

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.

Does Go have templating?

Nope! And that's most people's main problem with it.

Re: Why we switched from Python to Go

#152
post #140
post #6

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.

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.

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.

Re: Why we switched from Python to Go

#153

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

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.

Re: Why we switched from Python to Go

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

Re: Why we switched from Python to Go

#155

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

I think the article is not that bad. I specially like the comparison of : well python was a bit faster to develop with, but much longer to optimize. Note they actually used Python long enough to actually spend quite some time to consider the move to go; this means that performance of Python were ranging from good enough to barely enough for a (hopefully) long period of time. Also note the scale of operations of that company, if Python hold for say 10% of that scale, then it's certainly good enough for me !

That basically confirms the strength and weakness of python : it's very good for prototyping and if performance issues arise (and that can be later than one think), it's tough to optimize.

Re: Why we switched from Python to Go

#156

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

You're right that Go/Java have async style similar to Erlang. But the majority of production systems today that these languages run is some sort of web application. In this area, the Erlang VM holds its own pretty well, especially for websockets [1]. In that study Elixir's memory usage is higher, but total connections were almost identical to Go.

It'd be great if there were better benchmarks for common use cases of various languages. Spring on the Java side tends to be heavy on reflection usage, which is orders of magnitude slower than JIT'ed JVM methods. Benchmarks like the benchmark game don't capture this. Still despite that the Erlang VM performs very well on the benchmarks game compared to other dynamic/scripting languages. Often it's easily 5-10 times faster than Python or Ruby. Given the parents comment, I'd argue many programmers who enjoy developing with dynamic languages can do so with Elixir with comparable performance to Go/Java for high concurrency web applications.

1: https://hashrocket.com/blog/posts/websocket-shootout

Re: Why we switched from Python to Go

#157
post #89

Earlier quoted context omitted.

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 !

> shipping binary only Python extensions can be such a pain, especially dealing with 2-byte vs 4-byte unicode representation issues

The issue with different Unicode builds was fixed 5 years ago, in Python 3.3:

https://docs.python.org/3/whatsnew/3.3.html#pep-393-flexible...

Re: Why we switched from Python to Go

#158

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…

For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example. I won't say that Go is mainstream yet, but it feels very "production-rea…

I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight).

So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html).

Sounds about right :)

Re: Why we switched from Python to Go

#159
post #89

Earlier quoted context omitted.

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 !

> especially dealing with 2-byte vs 4-byte unicode

Wasn’t that solved years ago?

Re: Why we switched from Python to Go

#160

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.

Virtualenv is nice, but lately I've grown to use docker containers instead. You can use the official containers for go, python or ruby, feed it the gemfile or requirements.txt or whether, tag it, push it and you have a permanent snapshoted image.

Virtualenv is not nice; it's a pragmatic yet laughable hack.
Post reply on HN