Live data from Hacker News

Why we switched from Python to Go

getstream.io

331–340 of 406 posts

Re: Why we switched from Python to Go

#331
post #287

Earlier quoted context omitted.

Twitter's issue was more with concurrent IO than anything. This problem was solved about 10 years ago with the release of Ruby 1.9 and since then only one Ruby process per core is required, just like NodeJS. In that time most CPU intensive parts of the web stack have also been re-written as native extensions. Recent benchmarks of a properly setup Ruby environment vs Go/Gin are showing Ruby/Sinatra as having 50% of th…

Contrived benchmarks are not useful. Specially when you have tiny datasets. If you want to do anything interesting, Python/Ruby are slow as hell, which is why you cannot do anything interesting in them. For example, while in Go, you can load say 1000 rows from the db and perform some data manipulation on it in the code to get a desired result, you cannot do this in Python because it will very very slow. So what you d…

Simple benchmarks are a useful yardstick. I recently wrote a service in Rust/Iron which only has 4.7x the throughput of the same Ruby/Rails service. That was rather disappointing considering how much more effort is required to do it in a lower level language.

Is Python/Django performance significantly worse than Ruby/Rails? The situations you describe are things I do every day in Ruby. Getting 1000 rows from the DB and performing some operation only takes a couple of milliseconds in Ruby.

Ruby/Python are meant to be glue, and you can most certainly use them to glue together "interesting things", like image processing or audio processing in a web layer.

Memory caching rarely changed, often accessed, but ultimately persisted in a DB things like exchange rates in a global object is exactly what you do in Rails. There's a specific helper for doing it. http://api.rubyonrails.org/classes/ActiveSupport/Cache/Memor...

Re: Why we switched from Python to Go

#332

Earlier quoted context omitted.

and they are now seem invested in Ocaml/Reason (which are a lot less popular compared to Go) i guess after companies reach a certain size, they can go beyond choosing a programming platform for its ecosystem

Are they using much ocaml on the backend? At facebook's size they have a whole lot of different languages in the stack. I'd be very surprised if a significant portion of new backend development were in OCaml though.

you can check their github account, they have several static analysis tools written in ocaml

and then they have reason, is being used heavily in messenger

https://reasonml.github.io/community/blog/#messengercom-now-...

Re: Why we switched from Python to Go

#333
post #313

Earlier quoted context omitted.

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

> It'd be great if there were better benchmarks for common use cases of various languages Somebody should make those. (People may have different ideas about which use cases are common).

There are some: https://www.techempower.com/benchmarks/

As you can see, erlang is far from the top there.

Re: Why we switched from Python to Go

#334

Earlier quoted context omitted.

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.

Go also has tons of actor frameworks: https://github.com/AsynkronIT/protoactor-go

But it also has native coroutines embedded into language, which provide excellent asynchronous performance.

Re: Why we switched from Python to Go

#335

Earlier quoted context omitted.

I don't get how low latency GC can be a good selling point. I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once? Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percen…

Games. I like low latency and garbage collection. I feel like, hey, it's 2017, those things (along with performance within a reasonably small multiple of C's) really should go together.

Java and .Net games seem to have no problem getting into 120fps. Go's GC is optimized further.

Re: Why we switched from Python to Go

#336

Earlier quoted context omitted.

Is Go even memory-safe in the presence of data races? Don't get me wrong, “memory safety” isn't a hard requirement in my book, but “memory safety or a formal semantics” is.

If you're curious, the behavior is well defined: golang.org/ref/mem

My English reading comprehension is admittedly poor, but I don't see any portion of the text that automatically implies that unsynchronized reads and writes are atomic.

Re: Why we switched from Python to Go

#337
post #216

Earlier quoted context omitted.

If that's really the case, why do people spawn multiple instances of their app? A python application can be anywhere from 10x to 50x slower than a native application. It also probably consumes at least 5x more memory. Writing the same app in a compiled language is not even an optimization. It's just baseline work to ensure the code is not super slow. Like, if you know you will sort a list of 10 items, choosing quicks…

> why do people spawn multiple instances of their app For concurrency (number of requests handled at once) instead of speed (end-to-end time of of a single request)

This is not true. Java and Golang can use asynchronous IO and maintain thousands of concurrent connections. It's just another case where slow languages are... Slow

Re: Why we switched from Python to Go

#338

Earlier quoted context omitted.

Games. I like low latency and garbage collection. I feel like, hey, it's 2017, those things (along with performance within a reasonably small multiple of C's) really should go together.

Java and .Net games seem to have no problem getting into 120fps. Go's GC is optimized further.

120 fps is a measure of throughput, not latency. A high frame rate is good, but it's no guarantee that you're not going to drop a frame. Dropping a frame kills the experience, especially in VR.

In any case, .Net (and I gather Java) games typically go to considerable trouble to reduce GC pressure by pre-allocating memory pools and reusing them during execution. For certain kinds of games, like where you load everything in a level up front and don't deallocate until you finish, that can be fine. For other kinds of games, that's a nasty constraint to try to deal with. It ends up bending your architecture in ugly ways that make it hard to develop the game.

Re: Why we switched from Python to Go

#339

Earlier quoted context omitted.

Java and .Net games seem to have no problem getting into 120fps. Go's GC is optimized further.

120 fps is a measure of throughput, not latency. A high frame rate is good, but it's no guarantee that you're not going to drop a frame. Dropping a frame kills the experience, especially in VR. In any case, .Net (and I gather Java) games typically go to considerable trouble to reduce GC pressure by pre-allocating memory pools and reusing them during execution. For certain kinds of games, like where you load everythin…

Well, that's a good rationale. That's indeed a good reason to look into Go.
Post reply on HN