Two of my primary areas of professional interest are I gave a where I argued that static typing is an essential feature when picking a language for a large software project. For this reason, , I historically limited my use of Python to small projects with no more than a handful of files. Recently, I needed to build a command-line tool for work that could speak Thrift. I have been enjoying the / / / toolchain a lot recently, so my first instinct was to use for this new project, as well. However, it quickly became clear that if I went that route, . I couldn’t convince myself that my personal preference for JavaScript would justify such an investment, so I decided to take a look at Python. I was vaguely aware that there was an effort to add support for static typing in Python, so I Googled to find out what the state of the art was. It turns out that it is a tool named , and it provides , much like does for JavaScript or does for PHP. Fortunately, Mypy is more like Hack+HHVM than it is like Flow in that a Python 3 runtime accepts the type annotations natively whereas Flow type annotations must be stripped by a separate tool before passing the code to a JavaScript runtime. (To use Mypy in Python 2, you have to put your type annotations in comments, .) Although Mypy does not appear to be as mature as Flow (support for incremental type checking is still in the works, for example), simply being able to succinctly document type information was enough to renew my interest in Python. In researching how to use Thrift from Python, a search turned up some sample . After gradual typing, / is the other feature in JavaScript that I cannot live without, so this code sample caught my attention! As we recently added support for building projects in Python 3.6 at work, it was trivial for me to get up and running with the latest and greatest features in Python. (Incidentally, I also learned that you really want Python 3.6, not 3.5, as 3.6 has some important , , , !) Coming from , one thing that was particularly refreshing was rediscovering how Python is an edit/refresh language out of the box whereas JavaScript used to be that way, but is no more. Let me explain what I mean by that: I may be one of the last people you would expect to write an essay criticizing JavaScript, but here we are. JavaScript and “programming in the large.” presentation back in 2013 at mloc.js among others Nuclide Flow Babel ESLint JavaScript I would have to spend a lot of time up front on getting the Thrift bindings to work properly Mypy gradual typing Flow Hack operating in the style of the Google Closure toolchain Google Python code that spoke to Thrift using asynchronous abstractions async await improvements to Mypy fixes to the [asyncio](https://bugs.python.org/issue28613) API literal string interpolation like you have in ES6 and more the era of “modern” JavaScript In Python 3.6, I can create a new file in my text editor, write Python code that uses / and type annotations, switch to my terminal, and run to execute my code. example.py async await python example.py In JavaScript, I can create a new file in my text editor, write JavaScript code that uses / and type annotations, switch to my terminal, run , see it fail because it does not understand my type annotations, run , run , see it fail again because I don't have a that declares the plugin, rummage around on my machine and find a I used on another project, copy that to my current directory, run again, watch it fail because it doesn't know where to find , go back to the directory from which I took the file and now copy its file as well, remove the junk from that doesn't need, run , get impatient, kill , run , and run to execute my code. For bonus points, runs considerably slower than (with the type annotations stripped) because it re-transpiles every time I run it. example.js async await node example.js npm install -g babel-node babel-node example.js .babelrc babel-plugin-transform-flow-strip-types .babelrc .babelrc babel-node example.js babel-plugin-transform-flow-strip-types .babelrc package.json package.json example.js npm install npm install yarn install babel-node example.js babel-node example.js node example.js example.js Indeed, the JavaScript ecosystem offers all sorts of tools to speed up this process using daemons and caching, but you or someone on your team has to invest quite a bit of time researching, assembling, and maintaining a JavaScript toolchain for your project before anyone can write a line of “modern” JavaScript. Although you may ultimately achieve a nice edit/refresh workflow, you certainly will not have one out of the box as you would in Python. “ ” JavaScript is no longer an edit/refresh language. Another refreshing difference between JavaScript and Python is the “batteries included” nature of Python. If you look at the standard library that comes with JavaScript, it is fairly minimal. The Node environment does a modest job of augmenting what is provided by the standard library, but the majority of the functionality you need inevitably has to be fetched from npm. Specifically, consider the following functionality that is included in Python’s standard library, but must be fetched from npm for a Node project: deleting a directory argument parsing ( ) I can’t even… creating a temp file Logging (there are too many to options for me to decide which ones to link to) unit testing (again, ) too many to list printf format strings ( ) left-justify a string Node developers are still having nightmares over this one As you can see, for many of these features, there are multiple third-party libraries that provide overlapping functionality. (For example, if you were looking for a JSON parser, would you choose , , , , or ?) 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, 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. It might be possible that Python's third-party ecosystem is just as bad as npm's. What is impressive is that . I am aware that data scientists rely heavily on third-party packages like NumPy, but unlike the Node ecosystem, there is NumPy package that everyone uses rather than a litany of competitors named , , , etc. parse-json safe-json-parse fast-json-parse jsonparse json-parser the npm module named [logging](https://www.npmjs.com/package/logging) I have no idea whether that is the case because it is so rare that I have to look to a third-party Python package to get the functionality that I need one numpy-fast numpy-plus simple-numpy “We should stop holding up npm as a testament to the diversity of the JavaScript ecosystem, but instead cite it as a failure of JavaScript’s standard library.” For me, one of the great ironies in all this is that, arguably, the presence of a strong standard library in JavaScript would be the most highly leveraged when compared to other programming languages. Why? Because today, every non-trivial web site requires you to download underscore.js or whatever its authors have chosen to use to compensate for JavaScript’s weak core. When you consider the aggregate adverse impact this has on network traffic and page load times, the numbers are frightening. So…Are You Saying JavaScript is Dead? No, no I am not. If you are building UI using web technologies (which is a lot of developers), then I still think that JavaScript is your best bet. Modulo the emergence of (which is worth paying attention to), JavaScript is still the only language that runs natively in the browser. There have been many attempts to take an existing programming language and compile it to JavaScript to avoid “having to” write JavaScript. There are cases where the results were good, but they never seemed to be great. Maybe some transpilation toolchain will ultimately succeed in unseating JavaScript as the language to write in for the web, but I suspect we’ll still have the majority of web developers writing JavaScript for quite some time. Additionally, the browser is not the only place where developers are building UI using web technologies. Two other prominent examples are and . Electron is attractive because it lets you write once for Windows, Mac, and Linux while React Native is attractive because it lets you write once for Android and iOS. Both are also empowering because the edit/refresh cycles using those tools is much faster than their native equivalents. From a hiring perspective, it seems like developers who know web technologies (1) are available in greater numbers than native developers, and (2) can support more platforms with smaller teams compared to native developers. Indeed, I could envision ways in which these platforms could be modified to support Python as the scripting language instead of JavaScript, which could change the calculus. However, one thing that all of the crazy tooling that exists in the JavaScript community has given way to is transpiler toolchains like Babel, which make it easier for ordinary developers (who do not have to be compiler hackers) to experiment with new JavaScript syntax. In particular, this tooling has paved the way for things like , which I contend is one of the key features that makes React such an enjoyable technology for building UI. (Note that you can use React without JSX, but it is tedious.) To the best of my knowledge, the Python community does not have an equivalent, popular mechanism for experimenting with DSLs within Python. So although it might be straightforward to add Python bindings in these existing environments, I do not think that would be sufficient to get product developers to switch to Python unless changes were also made to the language that made it as easy to express UI code in Python as it is in JavaScript+JSX today. Web Assembly Electron React Native JSX Key Takeaways Python 3.6 has built-in support for gradual typing and async/await. Unlike JavaScript, this means that you can write Python code that uses these language features and run that file directly without any additional tooling. Further, its rich standard library means that you have to spend little time fishing around and evaluating third-party libraries to fill in missing gaps. It is very much a “get stuff done” server-side scripting language, requiring far less scaffolding than JavaScript to get a project off the ground. Although Mypy may not be as featureful or performant as Flow or TypeScript is today, the velocity of that project is certainly something that I am going to start paying attention to. By comparison, I expect that JavaScript will remain strong among product developers, but those who use Node today for server-side code or command-line tools would probably be better off using Python. If the Node community wants to resist this change, then I think they would benefit from (1) expanding the Node API to make it more comprehensive, and (2) reducing the startup time for Node. It would be even better if they could modify their runtime to recognize things like type annotations and JSX natively, though that would require changes to V8 (or Chakra, on Windows), which I expect would be difficult to maintain and/or upstream. Getting TC39 to standardize either of those language features (which would force Google/Microsoft’s hand to add native support in their JS runtimes) also seems like a tough sell. Overall, I am excited to see how things play out in both of these communities. You never know when someone will release a new technology that obsoletes your entire toolchain overnight. For all I know, we might wake up tomorrow and all decide that . Better set your alarm clock. we should be writing OCaml This post originally appeared on bolinfest.com . is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
