Live data from Hacker News

Why we switched from Python to Go

getstream.io

391–400 of 406 posts

Re: Why we switched from Python to Go

#391
post #289

Earlier quoted context omitted.

If that was the only reason (which it is not), it would still be a very good reason to stop writing code in these languages. Why waste 10x more memory?

> Why waste 10x more memory? That sort of question is totally missing the point of why people use these languages, yeah? Languages in the web world don't tend to be chosen based on memory requirements (or speed as this suggests). Are there cases where you want to think about that? Sure. People have plenty of reasons they'd want to use Python over Go, and vice versa.

The waste in memory is just an additional negative point.

"and vice versa" The only reason I would ever use python is for small scripts that I only run on my machine and don't need to deploy anywhere.

Maybe 10 years ago Python was an attractive language because Java sucked and C# only runs on windows and there weren't many other good choices.

Now there are many expressive languages that are also statically typed and fast. D, Swift, Kotlin, etc.

Re: Why we switched from Python to Go

#392
post #69
post #68

Earlier quoted context omitted.

Yeah, plus even if performance is important, the app layer isn't necessarily the best place to optimize. It doesn't really matter how fast you sprint between database calls if the database and its IO dominate your site's performance profile, which they often do...

Everyone seems to say this and also to write really slow websites.

They say this and write slow websites because they don't care. They only care about their code being "beautiful" in some weird sense.

Re: Why we switched from Python to Go

#393
post #389

Earlier quoted context omitted.

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.

It appears so: https://github.com/TomCrypto/caret

> This is an experiment for running Nim code on the ESP8266 ("NodeMCU") microcontroller. The end goal is an extendable framework on which to build autonomous ESP8266 applications, along with an associated web service which acts as a base station providing back-end message aggregation and front-end information display/control panel.

Re: Why we switched from Python to Go

#394

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

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…

Your 100-ish character phrase is probably the most succinct description of an idea I've frequently wanted to express.

Re: Why we switched from Python to Go

#395

Earlier quoted context omitted.

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.

Ah interesting! With that being true, then yes, I'd be surprised that it isn't faster too.

What about memory usage? That's an un-appreciated axis, IMO: for example, all of crates.io takes ~30mb resident, which is roughly the overhead for MRI itself, let alone loading code.

Anyway, the Rust team loves helping production users succeed, so if there's anything we can do, please let us know!

Re: Why we switched from Python to Go

#396

Earlier quoted context omitted.

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.

agreed. I was just stating something, not a counter at all.

Re: Why we switched from Python to Go

#397
post #289

Earlier quoted context omitted.

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

If that was the only reason (which it is not), it would still be a very good reason to stop writing code in these languages. Why waste 10x more memory?

Forking 10 processes does not use 10x the memory of a single process starting 10 threads. It's actually almost identical. Both are implemented by the kernel using clone(). Many older tools written in "fast" languages like PostgreSQL and Apache also use forking.

Re: Why we switched from Python to Go

#398
post #391

Earlier quoted context omitted.

> Why waste 10x more memory? That sort of question is totally missing the point of why people use these languages, yeah? Languages in the web world don't tend to be chosen based on memory requirements (or speed as this suggests). Are there cases where you want to think about that? Sure. People have plenty of reasons they'd want to use Python over Go, and vice versa.

The waste in memory is just an additional negative point. "and vice versa" The only reason I would ever use python is for small scripts that I only run on my machine and don't need to deploy anywhere. Maybe 10 years ago Python was an attractive language because Java sucked and C# only runs on windows and there weren't many other good choices. Now there are many expressive languages that are also statically typed and…

The ecosystem is a much bigger deal. There's an officially supported python library for every SaaS product on the market, and many libraries that are best-in-class in areas like data science. It takes minutes to write to pdfs, make graphical charts, edit images, and a million other nuancy, minor parts of apps that you want, but don't want to spend a ton of time writing.

Java is the only static language that features roughly equivalent levels of support ecosystem wide.

Re: Why we switched from Python to Go

#399
post #361

Earlier quoted context omitted.

I don't see Erlang listed at-all on that "Fortunes" page ?

They have elixir there, which is another language for Erlang VM, and they have erlang for other benchmarks.

JRuby is another language for JVM -- do you put forward JRuby as the example of JVM performance?

Re: Why we switched from Python to Go

#400
post #289

Earlier quoted context omitted.

If that was the only reason (which it is not), it would still be a very good reason to stop writing code in these languages. Why waste 10x more memory?

Forking 10 processes does not use 10x the memory of a single process starting 10 threads. It's actually almost identical. Both are implemented by the kernel using clone(). Many older tools written in "fast" languages like PostgreSQL and Apache also use forking.

We're not talking about forking here. Python/Ruby apps are actually spawned as several separate processes.
Post reply on HN