Comment by static_noise | Hacker News Reader

Comment by static_noise | Hacker News Reader

Parent Full thread

It's about managing your resources. You can simply buy the fastest processor for cheap money. You can buy systems with many cores or even build a cluster for considerable money.

But you can not buy time.

Developing python applications in many cases is much quicker than developing comparable applications in C++, C or Assembler. Therefore it makes a lot of sense for many companies to choose tools with quick development time to get the product running and care for performance later.

Since there may be so much code be written in python, it cannot simply be converted into a faster language since most critical parts are already accelerated using the proper libraries provided by the language ecosystem. Porting a complex application to another language in many cases is a really hard problem and might even not be possible to be done in smaller steps.

Therefore we need every bit of performance we can squeeze out of python. The whole world will gain from that. If we manage great strides like JavaScript it would be glorious!

Assembler isn't statically typed, and C and C++ are particularly bad examples of productive static languages. Go is a much better example, but it disproves your thesis that dynamic languages are more productive than static languages (I have 6 years of Python experience and 3 years of Go experience, and Go is at least as easy as Python for small, single-threaded code bases and it scales much better with team size, code volume, and thread count).

Yeah, but Go is 20-50% less productive, depending on who you ask. From my experience I'd say it's at least 25% less productive than Python. Not horrible but I think 25% is a minimum value and a quarter of your time adds up. I don't think it's worth the trade off once you consider every language has its warts, Go has its own problems.

That's not been my experience, and I'm a Python developer by trade. Python simply doesn't scale well with code size, team size, performance requirements, etc.

Go's biggest problem is a lack of generics, which means that in some cases, you have to fall back to duck typing. So the worst case is no worse than Python's best case.

My largest Go project has been 40KLOC, after which I felt that Python would've been at least 25% more productive.

The next-step isn't Go. It's Elixir. Or Rust if you need a systems language.

Also soon enough (if we aren't there already), fast hardware will be so cheap that the speed of execution at least for end user applications will rarely be a factor. Sure that database application you wrote in C is measurably faster, but can a human being detect the difference? More and more the response will be no.

In the last 5 years, clock speeds have stagnated. Hardware innovation has revolved around increasing cores and improving power efficiency. Unfortunately, Python and most other dynamic languages are poorly suited to take advantage of parallelism, so your C database can only get faster, but your Python database will not.

Honestly, the vast majority of languages are bad at parallelism. Dynamic vs. static doesn't have much to do with it. Task-parallel multicore (like goroutines and Web Workers and the like give you) is only a small fraction of what it means to "take advantage of parallelism", and if you're only using that (as opposed to SIMD, GPUs, concurrent data structures, work-stealing, etc.) then you are likely to see disappointing speedups in practice.

This is especially true in the last 5 years, which contrary to your post has seen a shift away from multicore task-parallel hardware (core counts are not increasing) and toward data-parallel hardware (wider SIMD lanes, better on-board GPUs, APU architectures, etc.)

You're missing the point. There's "suboptimal parallelism", and then there's "no parallelism". Python and many other dynamic languages fall into the latter category.

I'd call Python optimal parallelism. I prefer the scaling by instance method of Node and Python over the old ways- writing multithreaded Java apps. People can knock themselves out writing stuff like that if they want to. But my purposes have been well-served scaling by spinning up instances per-core.

For me, explicit pthreading should never be done except with systems software. In which case you're going to be using a systems language like C, C++ or Rust anyway. Not the oddball middletier stuff that isn't high or low level like Go, Java and C#.

Go's parallelism model is fundamentally different than the other languages you mentioned. Even if you never write any concurrent Go yourself, you could write single threaded routes and let the webserver handle the parallelism (this is more efficient than spinning up an OS thread per request). With Python, you also have to configure uwsgi or some such to deploy your application to each thread; with Go, the runtime handles this for you completely transparently--just run the binary and you're all set. Go isn't perfect, but using Python the way you are is just leaving money on the table.

In response to @pcwalton:

> In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent.

GIL doesn't matter, the OP said he was writing single threaded application. This means he's doing async (unlikely) or blocking the entire application process (not just the current request) on I/O.

> Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter.

Not as fast as goroutines, and spawn speed isn't the only (or even the most interesting) measure of efficiency--you can run several orders of magnitude more goroutines on a Linux box than you can threads. Of course, none of this is relevant to this conversation, since the OP is talking about running a single-threaded Python process per core.

> Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much.

You're conflating Go's concurrency model with its webserver implementation. Go's concurrency model (movable M:N coroutines with implicit yielding and a synchronous abstraction over async IO) is fundamentally different than the other approaches (threads and vanilla coroutines with some blend of sync and unabstracted async I/O).

Since you mentioned thread-per-connection, Go's "threads" are much lighter than even Linux threads, so you can service many more simultaneous connections (by many orders of magnitude in extreme cases). This is especially true if you're not using async I/O, and blocking I/O is the default for most of these other languages.

In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent.

> this is more efficient than spinning up an OS thread per request

Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter.

Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much.

>but using Python the way you are is just leaving money on the table.

Everything leaves some performance on the table. Everything also leaves some productivity on the table too.

Python is in my estimation 20-50% more productive as a language than Go. I run my web stuff on PyPy/gunicorn/Nginx which within reason, can't be leaving much to be wanted performance-wise.

I've given Go a good-go, but I haven't found anything that strikes that balance of ~25% more productive than Go, but still grant similar performance like PyPy does for me.

Reply on news.ycombinator.com