Live data from Hacker News

Why we switched from Python to Go

getstream.io

251–260 of 406 posts

Re: Why we switched from Python to Go

#251
post #207

Earlier quoted context omitted.

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

Well, we've seen for example, Twitter do that. I saw some slides[0] that other day from sometime in 2007[1] where they said they were using Ruby and spawning 180 rails instances to handle 600 requests per second. Like, that's insane. A compiled language can handle that load with just one instance. It's nothing. [0]: https://www.slideshare.net/Blaine/scaling-twitter/3-First_So... Also, if your audience is small enough…

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 the throughput https://www.techempower.com/benchmarks/#section=data-r14&hw=...

You can also just use JRuby and use a single JVM process. For small CLI apps, MRuby can even be compiled to C, then compiled as an executable.

Re: Why we switched from Python to Go

#252
post #158

Earlier quoted context omitted.

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 ). Soun…

So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P

They may be production ready, but have a quite small ecosystem compared to other languages mentioned.

Re: Why we switched from Python to Go

#253

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.

People who use Python are generally happy without it IMO. It's not a big deal.

people who use python more aren't as happy about it, otherwise mypy wouldn't exist.

i use python more, can't recommend mypy enough, it's great for what it is. it has warts, but that's to be expected if you add an optional strict modern type system to 20 years of dynamic language.

Re: Why we switched from Python to Go

#254

Earlier quoted context omitted.

So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P

They may be production ready, but have a quite small ecosystem compared to other languages mentioned.

Or there's not that many greenfield projects in any of them, for those that have managed to acquire the ecosystem years ago.

Re: Why we switched from Python to Go

#255
post #83

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 wonder the opposite. Hardly any system needs to process 500k response per second. But nearly all of them benefit from the developer productivity that Python/Rails offer. My current company has 15 Java & React engineers where 2 or 3 Rails would suffice. Load tops out at maybe a dozen requests/second. Feature development is super-slow. System complexity is off the charts.

> Feature development is super-slow. System complexity is off the charts.

That probably has little to do with language/stack and everything to do with constantly changing requirements/system growth.

To your required engineers comment, Spring Boot + jOOQ is easily one of the most productive backend stacks I've ever used. A single engineer could easily build a large API leveraging the stack.

Re: Why we switched from Python to Go

#256
Did you consider scala ?

I use it at work, and it is awesome. It has awesome error handling (Either/Option >>> exception) on my opinion, a much stronger type system (many errors are checked at compile). It is harder to learn, but you also have top notch package manager with the even bigger scala + java ecosystem.

Re: Why we switched from Python to Go

#257
post #190

Earlier quoted context omitted.

Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself. However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.

Hey Jelte, quick question: Did you guys try Numba or Cython? Or did you guys figure that the language simplification that Go provides would be worth it even if the performance considerations were similar?

No, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us.

Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite made us consider switching languages. Eventually we chose to rewrite our whole API codebase in Go for all the reasons in the article. (we did a small trial project in go first to evaluate it)

Re: Why we switched from Python to Go

#258

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

I haven't seen an xml configuration in years beyond some logger configurations. Spring Boot + jOOQ is simple to setup and works. It is my go-to for backend services. You will have to be okay with dependency injection which for some reason people have problems with.

It's important to remember that Java has been around for 20-30 years and it certainly has not stood still. Many of the complaints people have are from Java of 10+ years ago.

Re: Why we switched from Python to Go

#259

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…

Most of the time, runtime speed is far, far less important than developer speed.

I'd be curious what if any developer speed difference there is comparing a modern java stack (like Spring boot + jooq) with RAILs.

Re: Why we switched from Python to Go

#260

Earlier quoted context omitted.

In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.

Yeah, but 99% of libs won't return anything with additional accessible structure.

Yeah I think the point is, errors shouldn't be overloaded with too much extra structure. They should be errors. If additional structure is needed, it should probably be sent separately via the common multiple returns idiom in Go.
Post reply on HN