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

381–390 of 406 posts

Re: Why we switched from Python to Go

#381

Post by sjellis »

majewsky wrote: post #244
oblio wrote: 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

It was a very bad choice of words.

I wish that I knew a phrase to mean "has all of the documentation, tools, and libraries that are needed for an average team of developers following common practices to be likely to successfully ship and effectively maintain commercial projects, consistently".

Many really interesting languages and frameworks don't pass this criteria. It doesn't mean that they are a failure: the idea of programming languages that are designed for teaching or research, and are specifically not for commercial use, perhaps used to be more common than it is now.

Re: Why we switched from Python to Go

#382

Post by fijal »

JelteF wrote: post #190
Dowwie wrote: post #183

Wait just one minute, Thierry... Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python. You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've…

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.

Did you guys try PyPy before deciding to switch? If yes, what was the outcome? If not, why not?

Re: Why we switched from Python to Go

#383

Post by baq »

koffiezet wrote: post #284
dundercoder wrote: post #3

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…

I use both Go and Python regularly, and both have their uses and issues. Go for me is a rather simple tool that doesn't get in my way, and just lets you do stuff - on it's own it's relatively boring. While it's probably not everyone's cup of tea, I like it's simplicity. It does have some downsides the article here mentions like package management and versioning. I understand why vendoring is being pushed as 'the offi…

> In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away.

note that it is possible to pip install from git repos and it's actually very easy. you're just not expected to have to do that :)

Re: Why we switched from Python to Go

#384

Post by tychver »

steveklabnik wrote: post #353
tychver wrote: post #331

Earlier quoted context omitted.

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

Iron is still using sync IO, and while Ruby isn't great at parallel stuff, it at least does async IO, IIRC. That's going to be a huge difference.

Wow, steveklabnik replied to my comment! Unfortunately, both implementations of the service are CPU bound. I think we're running 25 threads in Iron but I'll have to check.

Re: Why we switched from Python to Go

#385

Post by tychver »

steveklabnik wrote: post #355
viraptor wrote: post #354

Earlier quoted context omitted.

It depends what you're doing. If you're running a ruby web app server and talking to the database, all the io you're doing is most likely synchronous. In the one-server-per-cpu model, anyway.

It's been a while, but I thought that MRI basically slept during IO and released the GIL so that other threads could do work. In that case, you'd still be handling more requests while the IO was performed. I could be wrong. This kind of thing: http://ablogaboutcode.com/2012/02/06/the-ruby-global-interpr...

Yeah, that's pretty much what happens. There's also non-blocking IO you can use with EventMachine but the DB drivers are a bit of an issue AFAIK.

Re: Why we switched from Python to Go

#386

Post by StavrosK »

steveklabnik wrote: post #377
StavrosK wrote: post #373

Earlier quoted context omitted.

These days I mostly do web, so Django and the whole ecosystem are just missing from Rust, but I'd settle for just the ORM. I found Diesel pretty hard to get started with, unfortunately :/ My other hobby is microcontrollers, and I would love it if I could run Rust on my ESP8266. I can already run MicroPython, but it feels a bit hacky (probably unfairly), and it would be amazing if I could use Rust and easily link in a…

Yeah, Diesel is tough; they're working on better docs which should help out quite a bit. IIRC someone is working on the ESP stuff... > I know this reply isn't useful Naw, it's all good: it's just as much about qualitative as quantitative. It's also because I'm writing a small framework in Rust in my spare time, so "rust for web" stuff is extremely top of mind for me. Thanks for taking the time :)

> they're working on better docs which should help out quite a bit.

That'd be great, because I currently can't find a niche where Rust is so much better than Python that I won't just fall back to that, impeding my Rust progress.

> IIRC someone is working on the ESP stuff...

That's what I heard too, but progress seems stalled. Hopefully, in the end, it'll be easy to run on the ESP, but the biggest problem is the ecosystem (which is also much of the reason why I don't use micropython all the time). There are so many libraries for the Arduino framework that C is hard to escape.

Re: Why we switched from Python to Go

#387

Post by tychver »

viraptor wrote: post #357
steveklabnik wrote: post #355

Earlier quoted context omitted.

It's been a while, but I thought that MRI basically slept during IO and released the GIL so that other threads could do work. In that case, you'd still be handling more requests while the IO was performed. I could be wrong. This kind of thing: http://ablogaboutcode.com/2012/02/06/the-ruby-global-interpr...

You're right that it can do async io. But you compared a framework to a language. Rust has Tokio for async - Iron is just not using it. It's similar with Ruby/RoR - yeah, they can do async. But not on their own. With unicorn server, you still get no threading and just a bunch of processes. With puma you can do threading (async cooperative really) - as long as you keep the configuration/code within the limits of what'…

It's definitely preemptive rather than cooperative. Ruby/Puma is actually using one OS thread per Ruby thread, so when one hits a DB call and blocks on sync IO, it releases the GVL and another Ruby thread can proceed. There's a timer thread Ruby runs and pre-empts each thread to schedule them.

Re: Why we switched from Python to Go

#388

Post by sametmax »

crimsonalucard wrote: post #362
sametmax wrote: post #322

Earlier quoted context omitted.

Google mypy for an introduction. Pycharm has good support for it if you want IDE integration. The stdlib is globally well annoted now. However, most 3rd party libs are not.

mixing untyped libraries with typed basically makes the whole monolith behave as if it was untyped. Once they get the major libraries typed, python projects will become much more robust.

It's not an all or nothing proposition. Gradual improvement is a thing.

Re: Why we switched from Python to Go

#389

Post by arc776 »

StavrosK wrote: post #301
sjellis wrote: post #139

Earlier quoted context omitted.

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…

Django's ecosystem has spoilt me so much that it's very hard to switch to another language, at least as far as web apps are concerned. I would love to play with Rust/Nim more, but most of the side-projects I'm passionate about involve at least a few things that Python has a lib for that would be a huge time sink to rewrite in another language.

Nim ameliorates this somewhat by being able to easily wrap any C/C++ libray, and even has c2nim to create wrappers automatically.

One of the advantages of compiling to C and C++.

Re: Why we switched from Python to Go

#390

Post by stavros »

arc776 wrote: post #389
StavrosK wrote: post #301

Earlier quoted context omitted.

Django's ecosystem has spoilt me so much that it's very hard to switch to another language, at least as far as web apps are concerned. I would love to play with Rust/Nim more, but most of the side-projects I'm passionate about involve at least a few things that Python has a lib for that would be a huge time sink to rewrite in another language.

Nim ameliorates this somewhat by being able to easily wrap any C/C++ libray, and even has c2nim to create wrappers automatically. One of the advantages of compiling to C and C++.

I wonder if it's easy to get Nim to run on the ESP8266, huh.
Post reply on HN