4 ms·

JavaScript vs. Python in 2017

65 points by thmslee 10y ago

harpocrates 10y ago
> I gave a presentation back in 2013 at mloc.js where I argued that static typing is an essential feature when picking a language for a large software project OK, so you went shopping for a statically typed language and somehow ended up with Python (which only _just_ started having annotations in 3.6)? Why not pick any of the multitudes of languages that actually do have static type-checking?
- meddlepal 10y ago
  I wonder if author confused static with strongly typed?
  - drodgers 10y ago
    Python was already strongly typed; the new type annotations just allow it to be explicitly typed too.
- ubernostrum 10y ago
  which only _just_ started having annotations in 3.6 This is incorrect. Python gained syntactic support for annotations of functions and methods in 3.0. It was anticipated that this feature would be used to annotate types of arguments and return values, but nothing about it required using it for this purpose (and in fact, nothing requires using it for that purpose today). Python 3.5 added the 'typing' module to the standard library (and it was also released standalone on the Python Package Index, allowing it to be installed on older versions of Python). This module provides a standardized way to describe types, and an ecosystem of tools has popped up which make use of the typing module's approach to perform static-style type checking of Python source code. Python 3.6 added syntax for annotating variables, and for declaring variables without assigning a value to them. Prior to this, type-checking tools used type-declaring comments to read the types of variables. Also, note that the annotations -- which are correctly termed "type hints" when used to describe types -- result in no enforcement whatsoever on the part of the Python runtime, which does not assign any special meaning to annotations, and aside from exposing them via an introspectable attribute will not do anything with them either prior to or during execution. To use them for type-checking purposes, you must install and run a third-party tool which reads the annotations and compares them to actual usage in the code.
  - azag0 10y ago
    ad the last point: Isn't this perfectly fine in principle (minus the fact that Mypy is third-party)? Compilers in static languages also work only with the source code, in a way, as there is no runtime interpreter. So there should be no reason for type checkers on dynamic languages to require the runtime. Granted, this forces you to essentially write type-statically in a dynamic language, which might limit your expressiveness, but that's probably your point anyway if you do type checking. Now I'm not saying that Mypy is anywhere near this hypothetical situation. My point is that type checkers over dynamic languages should not need the runtime in principle. Conversely, the runtime should not need to do the type checking, for performance.
    - ubernostrum 10y ago
      Many people, when they hear "static types for Python", expect that the Python interpreter would perform some kind of pre-execution step of checking types and usage, and refuse to execute code with type errors. Since this is not the case (and would be difficult/impossible to implement given that Python code can import new modules at any time, and also change the import paths), it's worth pointing out.
smilekzs 10y ago
> To make matters worse, npm module names are doled out on a first-come, first-serve basis. Much like domain names, this means that great names often go to undeserving projects. (For example, judging from its download count, the npm module named logging makes it one of the least popular logging packages for JavaScript.) This makes the comparison of third-party modules all the more time-consuming since the quality of the name is not a useful signal for the quality of the library. This is also my biggest complaint about global npm registry: lack of namespacing. > write JavaScript code that uses async/await and type annotations, switch to my terminal, run node example.js How about: node --harmony
jamesisaac 10y ago
Something this article glosses over is that JavaScript achieved all the benefits of ES6, ES7, gradual typing, etc, without breaking backwards compatibility. I can still pull in a library written 10 years ago alongside my fancy new async/await code. Perhaps this can be partly credited to JS's decision to go with a more minimal standard library, meaning it didn't end up with the Python 2/3 situation as standards evolved.
- milliams 10y ago
  I can do the same with a Python program written 8 years ago given that Python 3.0 was released in December 2008. I don't think that it's Python's large standard library that was the issue since that was immediately compatible with Python 3, rather it was the large ecosystem (in fact particularly a small number of popular packages) which held things back by not porting soon enough.
  - WorldMaker 10y ago
    The biggest issue was Python standardizing on Unicode by default in Python 3 and breaking backward compatibility with a lot of (bad) string handling code the hard way by also forcing developers to unlearn a lot of old habits. JS won't experience a directly similar thing because it started with default Unicode strings support (because it had to, and also because JS is slightly younger than Python and had that advantage).
andreareina 10y ago
To the best of my knowledge, the Python community does not have an equivalent, popular mechanism for experimenting with DSLs within Python. I think this is because modern javascript practice already includes a compiler pipeline to handle modules, polyfills, etc so one more step doesn't really matter. In contrast, since Python already works out of the box, even one extra step incurs a large step. (Linters and such don't count because I can run my unlinted code as is; I can't run my custom DSL without preprocessing it).
krystiangw 10y ago
In terms of popularity Javascript clearly wins. According to stats: https://jobsquery.it/stats/language/group https://jobsquery.it/stats/language/group JavaScript is mentioned in 17% of all tech job offers VS 10% for Python. However in terms of average salary - Python is the winner. Average salary for Python openings is $117k annually VS $96k for Javascript. (same stats page https://jobsquery.it/stats/language/group https://jobsquery.it/stats/language/group )
- collyw 10y ago
  Most job offers require more than one language - often a front end language and a back end language so its not surprising that JavaScript is higher as its the only real option on the front end. I use both in my job but I spend far more time in Python (and as far as preference goes Python wins hands down over JS).
Can_Not 10y ago
> JavaScript is no longer an edit/refresh language. That's weird, my edit/refresh experience didn't disappear, even after adding Babel/typescript. In fact, maybe you could say it's more advanced and powerful after adding live reloading?

65 points by thmslee 10y ago

> I gave a presentation back in 2013 at mloc.js where I argued that static typing is an essential feature when picking a language for a large software project OK, so you went shopping for a statically typed language and somehow ended up with Python (which only _just_ started having annotations in 3.6)? Why not pick any of the multitudes of languages that actually do have static type-checking?

meddlepal 10y ago
I wonder if author confused static with strongly typed?
- drodgers 10y ago
  Python was already strongly typed; the new type annotations just allow it to be explicitly typed too.
ubernostrum 10y ago
which only _just_ started having annotations in 3.6 This is incorrect. Python gained syntactic support for annotations of functions and methods in 3.0. It was anticipated that this feature would be used to annotate types of arguments and return values, but nothing about it required using it for this purpose (and in fact, nothing requires using it for that purpose today). Python 3.5 added the 'typing' module to the standard library (and it was also released standalone on the Python Package Index, allowing it to be installed on older versions of Python). This module provides a standardized way to describe types, and an ecosystem of tools has popped up which make use of the typing module's approach to perform static-style type checking of Python source code. Python 3.6 added syntax for annotating variables, and for declaring variables without assigning a value to them. Prior to this, type-checking tools used type-declaring comments to read the types of variables. Also, note that the annotations -- which are correctly termed "type hints" when used to describe types -- result in no enforcement whatsoever on the part of the Python runtime, which does not assign any special meaning to annotations, and aside from exposing them via an introspectable attribute will not do anything with them either prior to or during execution. To use them for type-checking purposes, you must install and run a third-party tool which reads the annotations and compares them to actual usage in the code.
- azag0 10y ago
  ad the last point: Isn't this perfectly fine in principle (minus the fact that Mypy is third-party)? Compilers in static languages also work only with the source code, in a way, as there is no runtime interpreter. So there should be no reason for type checkers on dynamic languages to require the runtime. Granted, this forces you to essentially write type-statically in a dynamic language, which might limit your expressiveness, but that's probably your point anyway if you do type checking. Now I'm not saying that Mypy is anywhere near this hypothetical situation. My point is that type checkers over dynamic languages should not need the runtime in principle. Conversely, the runtime should not need to do the type checking, for performance.
  - ubernostrum 10y ago
    Many people, when they hear "static types for Python", expect that the Python interpreter would perform some kind of pre-execution step of checking types and usage, and refuse to execute code with type errors. Since this is not the case (and would be difficult/impossible to implement given that Python code can import new modules at any time, and also change the import paths), it's worth pointing out.

smilekzs 10y ago

> To make matters worse, npm module names are doled out on a first-come, first-serve basis. Much like domain names, this means that great names often go to undeserving projects. (For example, judging from its download count, the npm module named logging makes it one of the least popular logging packages for JavaScript.) This makes the comparison of third-party modules all the more time-consuming since the quality of the name is not a useful signal for the quality of the library. This is also my biggest complaint about global npm registry: lack of namespacing. > write JavaScript code that uses async/await and type annotations, switch to my terminal, run node example.js How about: node --harmony

jamesisaac 10y ago

Something this article glosses over is that JavaScript achieved all the benefits of ES6, ES7, gradual typing, etc, without breaking backwards compatibility. I can still pull in a library written 10 years ago alongside my fancy new async/await code. Perhaps this can be partly credited to JS's decision to go with a more minimal standard library, meaning it didn't end up with the Python 2/3 situation as standards evolved.

milliams 10y ago
I can do the same with a Python program written 8 years ago given that Python 3.0 was released in December 2008. I don't think that it's Python's large standard library that was the issue since that was immediately compatible with Python 3, rather it was the large ecosystem (in fact particularly a small number of popular packages) which held things back by not porting soon enough.
- WorldMaker 10y ago
  The biggest issue was Python standardizing on Unicode by default in Python 3 and breaking backward compatibility with a lot of (bad) string handling code the hard way by also forcing developers to unlearn a lot of old habits. JS won't experience a directly similar thing because it started with default Unicode strings support (because it had to, and also because JS is slightly younger than Python and had that advantage).

andreareina 10y ago

To the best of my knowledge, the Python community does not have an equivalent, popular mechanism for experimenting with DSLs within Python. I think this is because modern javascript practice already includes a compiler pipeline to handle modules, polyfills, etc so one more step doesn't really matter. In contrast, since Python already works out of the box, even one extra step incurs a large step. (Linters and such don't count because I can run my unlinted code as is; I can't run my custom DSL without preprocessing it).

krystiangw 10y ago

In terms of popularity Javascript clearly wins. According to stats: https://jobsquery.it/stats/language/group https://jobsquery.it/stats/language/group JavaScript is mentioned in 17% of all tech job offers VS 10% for Python. However in terms of average salary - Python is the winner. Average salary for Python openings is $117k annually VS $96k for Javascript. (same stats page https://jobsquery.it/stats/language/group https://jobsquery.it/stats/language/group )

collyw 10y ago
Most job offers require more than one language - often a front end language and a back end language so its not surprising that JavaScript is higher as its the only real option on the front end. I use both in my job but I spend far more time in Python (and as far as preference goes Python wins hands down over JS).

Can_Not 10y ago

> JavaScript is no longer an edit/refresh language. That's weird, my edit/refresh experience didn't disappear, even after adding Babel/typescript. In fact, maybe you could say it's more advanced and powerful after adding live reloading?