3 ms·

The same problems you cite for node.js are the reasons why a lot of devs love node.js. Its much easier to do your own research and find the best module to solv

The same problems you cite for node.js are the reasons why a lot of devs love node.js. Its much easier to do your own research and find the best module to solve a particular problem you are having then to shoehorn into some larger monolithic framework. Also its a lot more fundamental then that - Node.js has prolly the fastest iteration cycle for any platform out there since its so easy to create your own module - it leads to some sort of Cambrian explosion of innovation and experimentation. EDIT: Also OP seems to think callback hell and async programming is bad. The important thing is those things are problems for python/.... too ! Its just that python doesn't have a good programming model to even begin to address those concerns. JavaScript at-least tries to say - "hey this is a problem we need to deal with - concurrency is a issues we all face " So when devs complain about callback hell - its just that they have never tried to use python to do async in a neat way.

empthought 10y ago
> python doesn't have a good programming model to even begin to address those concerns This isn't even close to true. Anything JavaScript has to express logic in the face of asynchrony, Python has too. There are a half-dozen asynchronous web servers written in Python. There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program, and threads/OS processes are good enough for basically everything except HTTP servers with absurd numbers of concurrent connections.
- wrong_variable 10y ago
  > There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program. > everything except HTTP servers with absurd numbers of concurrent connection Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.
  - empthought 10y ago
    It's not like we didn't have cooperative multitasking for 50 years. Having threads/processes and a scheduler is easier and safer, full stop. Potentially long-running portions of the program don't need to be arbitrarily chopped up to yield control back to the server, because they are pre-empted. Your system is no longer at the mercy of the worst code within it. Both nginx and Apache's event MPM handle HTTP connections with events while the app backends are still using preemptive threads for running the HTTP handler code, so it's clearly not the case that "you need to make the whole thing event driven." You just need programmers who don't think, "well since the browser doesn't expose threads to JavaScript programmers, clearly they are useless."
Someone 10y ago
That Cambrian explosion is fun when you are programming, but if you are writing a product, you will want to make sure you don't pick a dinosaurus or trilobite to build it on.

empthought 10y ago

> python doesn't have a good programming model to even begin to address those concerns This isn't even close to true. Anything JavaScript has to express logic in the face of asynchrony, Python has too. There are a half-dozen asynchronous web servers written in Python. There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program, and threads/OS processes are good enough for basically everything except HTTP servers with absurd numbers of concurrent connections.

wrong_variable 10y ago
> There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program. > everything except HTTP servers with absurd numbers of concurrent connection Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.
- empthought 10y ago
  It's not like we didn't have cooperative multitasking for 50 years. Having threads/processes and a scheduler is easier and safer, full stop. Potentially long-running portions of the program don't need to be arbitrarily chopped up to yield control back to the server, because they are pre-empted. Your system is no longer at the mercy of the worst code within it. Both nginx and Apache's event MPM handle HTTP connections with events while the app backends are still using preemptive threads for running the HTTP handler code, so it's clearly not the case that "you need to make the whole thing event driven." You just need programmers who don't think, "well since the browser doesn't expose threads to JavaScript programmers, clearly they are useless."

Someone 10y ago

That Cambrian explosion is fun when you are programming, but if you are writing a product, you will want to make sure you don't pick a dinosaurus or trilobite to build it on.