6 ms·

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 co

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!

cmdrfred 10y ago
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.
- weberc2 10y ago
  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.
  - pcwalton 10y ago
    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.)
    - weberc2 10y ago
      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.
      - BuckRogers 10y ago
        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#.
        weberc2 10y ago
        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.
        pcwalton 10y ago
        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.
weberc2 10y ago
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).
- BuckRogers 10y ago
  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.
  - weberc2 10y ago
    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.
    - BuckRogers 10y ago
      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.

cmdrfred 10y ago

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.

weberc2 10y ago
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.
- pcwalton 10y ago
  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.)
  - weberc2 10y ago
    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.
    - BuckRogers 10y ago
      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#.
      - weberc2 10y ago
        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.
        pcwalton 10y ago
        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.

weberc2 10y ago

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

BuckRogers 10y ago
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.
- weberc2 10y ago
  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.
  - BuckRogers 10y ago
    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.