
JavaScript vs. Python in 2017 - thmslee
https://hackernoon.com/javascript-vs-python-in-2017-d31efbb641b4#.e6fhkgl4i
======
jamesisaac
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
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
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).

------
smilekzs
> 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

------
andreareina

        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).

------
harpocrates
> 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?

~~~
ubernostrum
_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
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
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.

------
krystiangw
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
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
> 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?

