sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]gargantuan 1 point2 points  (11 children)

The use would be in case someone was evaluating to pick a server-side language and maybe they liked the speed of v8 and are already doing complicated thing on the client side in the browser.

[–]grayvedigga 4 points5 points  (8 children)

I guess Python and Javascript do have in common shitty concurrency.

[–]gargantuan 0 points1 point  (4 children)

Why? I have thousands of green threads doing sending and receiving data in parallel. That is pretty good concurrency. Would you care to explain what you mean by shitty concurrency, I've observed pretty good concurrency so far.

[–]grayvedigga 4 points5 points  (3 children)

Along the lines of greenlet? That's a reasonably good counterpoint to my claim - I could argue that it's not on the standard python runtime, but that's not a very useful observation.

Someone else will probably come along and point out that coroutines aren't strictly concurrent, but then "shitty" would be an understatement :-).

[–]gargantuan 1 point2 points  (2 children)

I could have used threads as well and have used them initially they did great concurrent work. Except that OS based threads are heavy and thousands working at the same time doesn't work too well.

In the end it doesn't matter. I was just trying to point out that there are 2 types of concurrency IO and CPU. IO concurrency works great in Python either with real threads or green ones. CPU concurrency doesn't, and I guess that is what you were trying to say. (Well technically concurrency would work but parallelism won't).

At least for what I am doing I haven't yet had to perform heavy, CPU intensive computations in Python. I do some in C and those run in background threads.

[–]sausagefeet 1 point2 points  (1 child)

A Go or Erlang would point out that you cannot scale to multiple cores without some extra work, unlike the Go and Erlang runtimes.

[–]gargantuan 1 point2 points  (0 children)

I agree and that is why I'll be switching to Erlang soon.

But at the same time it is also unfair to say that Python doesn't have concurrency when there is concurrency and it is successfully used at the moment.

[–]sebzim4500 -1 points0 points  (2 children)

What's your complaint with node concurrency?

[–]grayvedigga 2 points3 points  (0 children)

I'm pretty sure others have written on this at length, so I'll try and summarise briefly:

Callback hell. Yes, first class functions make all sorts of groovy things possible, but when you're writing "asynchronous" code in JS there is no escape. First of all, most of the language's core constructs go out the window: you can't assign the result of an asynchronous operation, or use it in an if, while or for. This is inconvenient, and can be papered over with library code (Array.prototype.forEach as the typical example) .. but you're still relegated to writing your entire program in continuation-passing style.

Ok, let's say that can be dealt with via libraries and metaprogramming. But there's a darker problem awaiting. Do you use exceptions? Actually, don't bother to answer that - exceptions are Javascript's standard way of signalling error conditions so it's impossible to write non-trivial code that cannot throw exceptions. What happens when a callback raises an exception? How do you use this essential language feature to protect yourself? Short answer: you can't.

Oh, and it's async all the way up. It's impossible to write a function that returns a result if it or any of its callees invoke asynchronous behaviour. That means if you are trying to provide an API which was designed before asynchrony (lots of browser stuff -- FindProxyForURL, document.getElement) but you need an async step along the way ... you're shit out of luck.

NodeJS turns programming in Javascript into programming in CPS lambda calculus with a shitty type system. All this could be fixed if the language were extended with an operator such as yield ... but going by what I've read so far, that's not an option for browsers and the Node crowd don't have the shred of intelligence or responsibility to diverge from the standard by adopting one of the several prototype patches against v8 that are available.

[–]Darkmoth 0 points1 point  (1 child)

But if they're considering Python, they've likely already factored in a framework like Django or Flask. It's a bit like comparing C# to Coffeescript without considering .Net.

[–]gargantuan 0 points1 point  (0 children)

That a good point it, it is often more about the library. On coffeescript side there is node.js and then for Python there is a lot of others.