I agree: if you need to use multicores, multiprocessing is simpler, faster and safer than threading.
NaCl is becoming more and more interesting. https://developers.google.com/native-client/ It is going to LLVM so maybe in a not too far future web2py will enjoy pushing some pypy generated vm on the client. In the mean time if we want to stop having people go after javascript, we need to extend web2py to the client. A basic idea can be the defining a basic set of widgets and simple wire protocol (ajax, json...) to push events to web2py. So a button would be: class BUTTONW(WIDGET): . . . def onclick(self, target): . . <do stuff> . target.update() Serialization of BUTTONW creates the needed javascript so one can simply write: {{=BUTTON(id='id1', target='<some way to identify objects>')}} The target objects are objects whose state is know to web2py so that they can be serialized back to the client on request (target.update()) If the widget tree becomes big, so to satisfy most usage patterns, then using web2py would help reducing the usage of javascript. Of course there would still be javascript underlying, as there is assembler as a result of a compilation, but how many care about assembler today? mic Il 30 marzo 2012 16:01, Wikus van de Merwe <[email protected]> ha scritto: > I don't agree that multiprocessing is difficult in Python. Threading is > difficult, multiprocessing is easy. Together with asynchronous I/O this > brings the scalability. You think node.js is multithreading? No, it's single > thread with event loop and non-blocking callbacks based I/O. And so is > Twisted or Eventlet and they perform equally well. If you need to scale you > add another instance of the event loop running on a separate core and route > your traffic through a load balancer. > > I also disagree that python 3.x is a problem. It is a better language than > 2.x. It's a shame that the transition of many projects is happening so slow. > If the life of 2.x is extended it will only cause further delays in > transition to 3.x. > > Also, in all this discussion on how tragic it is that Python has been > surpassed by the Javascript, we need to remember that TIOBE index is > calculated by counting hits on the top 9 search engines using a query of > "<language> programming". And as Derek has already spotted the query for > Javascript has been extended and includes "JS programming" too [1]. I think > it is much more reasonable to count the number of commits in a given > programming language like ohloh is doing [2]. Then Python is not so much > behind Java/C/C++ and is recovering from a drop in activity in 2011. > > [1] > http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm > [2] http://goo.gl/suOH6
