Hacker News new | past | comments | ask | show | jobs | submit login

I believe the most amazing feature of JS is the ability to make their devs think they got it all figured out.

> Python relatively recently added typing[0]

The typescript compiler and the mypy type checker both appeared in 2012.

Function annotations have also been officially part of the Python syntax since 2006, although they could be used for more than typing.

Browsers still do not support the typescript syntax as of today, you need a transpiler.

> parallelism support (recently in v11 w/ worker threads), and built in async IO paradigms give Node a huge leg up over ruby, python, and perl.

Python has supported non blocking processing as far as 21 years ago with threads. It's actually the language of choice for pentesting a networks because it's so easy to implement a custom service scan.

Python then, in 2002, saw the rise of Twisted for pure asynchronous I/O + callbacks, as it was for JS and AJAX at the time. Ansyncio came way later, yet Python implemented async/await and yield before it was part of JS.

Python implemented multiprocessing as well, which allows to leverage multiple cores, more than 10 years ago. I remember that producing the equivalent result ishard to use accross all major browsers, and nodejs, consistently. The Python multiprocessing pool has even not changed API when we migrated from Python 2 to 3 and works with both (I just tried it to be sure).

> Weirdly enough, JS is the best in my opinion precisely because it does so much to not be itself.

I think you should try to put in production 4 or 5 other languages before stating such a strong opinion. Your post feels more like over enthousiasm due to lack of experience than a real analysis of the state of dynamic programming languages.

There are strong qualities to Perl, PHP, Python and Ruby. The fact they are so popular without having an accidental absolute monopoly on the most extraordinary plateform of the world (the Web) should at least give you a hint of that.




> The typescript compiler and the mypy type checker both appeared in 2012.

> Function annotations have also been officially part of the Python syntax since 2006, although they could be used for more than typing.

> Browsers still do not support the typescript syntax as of today, you need a transpiler.

I did not make a statement about the typescript compiler/transpiler nor mypy, I made a statement about the typing module which was brought about by PEP 484 (proposed in 2014) and accepted in 2015 a full 3 years after the typescript compiler came on the scene. JS got gradual typing first, even if it was through transpilation -- there are even earlier examples of syntax enhancement (though it was mostly sugar) with coffee script from even earlier.

JS is undeniably more innovative in this aspect -- it's also made more mistakes as well.

It doesn't matter what browsers support, because the code is transpiled. The point is that you have access to better tools as a developer while writing code.

Is your point that python have been specifying their types in their code in any sort of numbers since mypy was invented? Because I sure don't see that on slides PyCons over the last ~5 years.

> Python has supported non blocking processing as far as 21 years ago with threads. It's actually the language of choice for pentesting a networks because it's so easy to implement a custom service scan.

> Python then, in 2002, saw the rise of Twisted for pure asynchronous I/O + callbacks, as it was for JS and AJAX at the time. Ansyncio came way later, yet Python implemented async/await and yield before it was part of JS.

There's a difference between what's possible and what's easy/facilitated well by the standard library of a language. I did not imply that python could not do non-blocking processing. My point was that these patterns were not easy and were not standard -- and the community floundered for years between alternate solutions (gevent/twisted/tornado), eventually creating asyncio while NodeJS has had support for this feature built in from the start.

Also I'm not sure that pentesting stat is correct -- ruby is extremely popular and so is/was perl. Scripting languages with decent standard libraries and easy semantics are popular, not necessarily non-blocking processing support.

> Python implemented multiprocessing as well, which allows to leverage multiple cores, more than 10 years ago. I believe producing the equivalent result is still hard to use accross all major browsers, and nodejs, consistently. The Python multiprocessing pool has even not changed API when we migrated from Python 2 to 3 and works with both (I just tried it).

Please see the other comments. No one is saying multi processing is impossible in python, I specifically called out that it's done by starting other processes. There are subtle differences between how node worker threads and multi-process setups work, in particular the shared memory space and communication mechanisms. The GIL is also an issue.

> I think you should try to put in production 4 or 5 other languages before stating such a strong opinion. Your post feels more like over enthousiasm due to lack of experience than a real analysis of the state of dynamic programming languages.

> There are strong qualities to Perl, PHP, Python and Ruby. The fact they are so popular without having an accidental absolute monopoly on the most extraordinary plateform of the world (the Web) should at least give you a hint of that.

So your point is that everything is different and everything has it's own benefits? Well that's impossible to refute so I'm just going to restate my point, maybe you can try and refute it directly.

Javascript has the accessible (and thus widely adopted) and easy to use implementation of the following features, today in 2019:

- Rigorous and powerful compile time type checking

- Parallel computation (without spawning another process or the effects of a GIL)

- Asynchronous IO

The combination of these three features being accessible is what makes Node stand out in front of Perl, PHP, Python, and Ruby.

Python may have "had" the capability to do the things above at various times in the past, but it's technically been capable of doing just about anything, like any other programming language -- you can launch sub-processes from bash, doesn't mean you should use it for large applications. What makes a good language is accessible and easy to use features that make you both correct and productive.

Node has more of these tools available, and they're more accessible in Node than they are in Python, and more people are using them. Typescript offers more robust type support than typing+mypy. Node worker threads, though very recent, provide parallel computation without child subprocesses, in a shared memory context with no GIL. Asynchronous IO is second nature to JS developers, while that's definitely not the case for python developers.

[0]: https://www.python.org/dev/peps/pep-0484/


> I did not make a statement about the typescript compiler/transpiler nor mypy, I made a statement about the typing module which was brought about by PEP 484 (proposed in 2014) and accepted in 2015 a full 3 years after the typescript compiler came on the scene. JS got gradual typing first -- there are even earlier examples of syntax enhancement (though it was mostly sugar) with coffee script from even earlier.

> JS is undeniably more innovative in this aspect -- it's also made more mistakes as well.

JS has none of that. Typescript has it. They are not the same thing.

I'm comparing an external tool with an external tool. Mypy could type check Python before it was officially in the stdlib, just like the typescript type checker can make it so. Type annotations are not part of JS.

> It doesn't matter what browsers support, because the code is transpiled. The point is that you have access to better tools as a developer while writing code.

It does very much. Transpiling is not a free operation, and comes with a lot of pros and cons.

It's also not a universal operation. Most JS projects do not use typescript. Many projects still don't even use a transpiler at all.

> There's a difference between what's possible and what's easy/facilitated well by the standard library of a language. I did not imply that python could not do non-blocking processing. My point was that these patterns were not easy and were not standard

JS async were not easy neither at the begining. We had a decade of callback hell, then another war about the promise implementation, all that wrapped up in code to make browser differences manageable. Not to mention the 2 nodejs forks in it's small lifetype, JXcore rewritting the entire async model.

Let's also not forget we managed to scale web services way before NodeJS was a thing, with dozen of languages.

Yes, making an async HTTP request is more natural in JS than in Python. It would be a shame, JS is a Web oriented language while Python is a polyvalent language. However, I have yet to witness a service where this would have made such a huge difference all in all. Even facebook use long polling if I recall, something you can do with threads easily on the client side, and support with a proxy such as nginx as a front end even with nodejs as a backend.

> Javascript has the accessible (and thus widely adopted) and easy to use implementation of the following features, today in 2019:

> - Rigorous and powerful compile time type checking

Not JS. Typescript. And typescript and mypy came out together.

> - Parallel computation (without spawning another process or the effects of a GIL)

Web worker consume a similar order of magniture of resources than a python instance, and communicate data by message passing the same way. And no GIL.

The difference ? Python came fist, and has a more consistent support (you need fallback in JS if you use it in a website). I don't think we should be proud of it, but it's not the middle age you are talking about.

> - Asynchronous IO

> The combination of these three features being accessible is what makes Node stand out in front of Perl, PHP, Python, and Ruby.

The advantage of JS is historically a better async API. Let's not overstate this though.

And even if JS were vastly superior in all those area (which is, again, overstated), it hardly is enough to draw the conclusion that:

> as the best feature set of the "scripting language" tier of interpreted programming languages

Readability, ease of automation, rich stdlib, ecosystem, ability to deal with formatting/parsing/date handling, community culture and so much more are as important, if not more important, for a scripting language. Scripting, after all, goes far beyond the Web.

> Python may have "had" the capability to do the things above at various times in the past, but it's technically been capable of doing just about anything, like any other programming language -- you can launch sub-processes from bash, doesn't mean you should use it for large applications. What makes a good language is accessible and easy to use features that make you both correct and productive.

Youtube having been rewritten in Python proves that it was more than being capable. It also powers instagram and reddit.

When google rewrites their Python services for perf, they don't go for JS, they choose Java, C or Go. That's because again, Python is at the same order of magnitude of perf than JS on average.

> Node has more of these tools available, and they're more accessible in Node than they are in Python, and more people are using them.

Yes, JS is a Web language. That doesn't make it the ultimate scripting language.

> Typescript offers more robust type support than typing+mypy.

This is a gratuitious claim. Espacially since typing is in the stdlib, while typscript annotation are a syntax error in Emascript.

> Node worker threads, though very recent, provide parallel computation without child subprocesses, in a shared memory context with no GIL.

Objects passed to web workers are serialized and deserialized, just like with python multiprocessing.

> Asynchronous IO is second nature to JS developers, while that's definitely not the case for python developers.

Doing Ajax call being the based of today's web, the contrary would be alarming.


> Transpiling is not a free operation, and comes with a lot of pros and cons.

You could say the same for languages that require compilation, it's not exactly an uncommon pattern. JS will almost always have some kind of operation applied to it when running on the web (minification etc) so adding TypeScript transpilation is often a very small step.

Is that ideal? No. But Python doesn't even run on the web, so of course it doesn't have these issues.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: