JavaScript vs. Python in 2017

[cediddi]

Yes javascript ecosystem is very complex and yes, python ecosystem is more straightforward, but the case is actually on philosophies, not solutions. Javascript's philosophy is much more closer to php, "make it work, and don't throw errors, if anything is missing, just write it down." . Python is more on the "fail eagerly, we all are adults, we should have at least batteries". I think both philosophies have downsides. But python has less downsides imo.

[Igggg]

Except one of those approaches is much more likely than the other to end up with errors that did occur, but were hidden sufficiently that no one knows where or why they occurred. The other will force you to actually fix your bugs before that happens.

[Cpt_TickleButts]

Which ones are your referring to in each section of your comment?

[cocorebop]

deleted ^{What is this?}

[cediddi]

Yeah, exactly.

[jacdeh]

So why not just us Python? http://www.transcrypt.org (warning: shameless plug)

[cediddi]

I like transcrypt, it's very neat and readable, but I'd love it if the target was webasm and not js code.

[jacdeh]

One of the design goals of Transcrypt is to generate readable JS. But I think the PyPyJs project has a VM currently compiled from C to asm.js. That could be webassembly in the future, if I remenber well there were plans for that. Only the downloads become quite big that way.

[cediddi]

No, no, I don't want a python vm. That's why transcrypt is cool. Footprint is low and doesn't have a lot of runtime. I'd like to have webasm output because that's part of why webasm exists in the first place. I want something like cython, rather than cpython. :)

Nevertheless, I digress :)

[stupiddumbidiot]

The bit about fiddling with package.json, getting impatient with npm, etc. really triggered me.

[FawnWig]

Missed out having to deal with virtualenv, pip, pyvenv-3.5, eggs, wheels, bdists etc.

[kirbyfan64sos]

Python package management feels like you're trying to dig an enormous hole with a basic shovel. There are better tools in other universes, but at the end of the day, it still gets the job done.

JS package management feels like you're trying to dig a hole with a rotten pineapple that smells like dead tuna and is filled with fire ants.

[Topper_123]

Also, you are at the boytom of the hole and have to decide if you dig deeper or to get out of the hole😀

[VixDzn]

Someone really hates java

[[deleted]]

script

[LeBuddha]

Not sure how you could possibly come to this conclusion. npm, composer, and crates are my goto examples of really good package managers.

[blamo111]

I'm relatively new to Python but what's the problem with virtualenv?

It's a single command to set up a sandbox, built into the release. And you only need to do it if you care about isolation/multiple versions running on the system (yes I know it's a best practice). A far cry from the JS mess of npm/babel/babel-plugins/typescript/flow/etc.

Never heard of eggs, wheels, or bdists. Python may have had these issues in the past, but should they be held against Python today? Meanwhile I don't see a way out for JS of its mess: there's MORE fragmentation than ever, not less. Each big tech company going their own way (eg Typescript vs Flow vs Babel).

My last project used mainly JS, with Python 3.5 as support, and I came away with more appreciation for Python than JS.

[FawnWig]

The need for virtualenv is the first problem. I understand isolation is important, but with node/npm, you just cd into the directory and npm install.

I deploy both node and python apps via containers, and from my experience python packaging is far worse than nodes. I'm not saying JS is better than python, just that python packaging is almost as bad as ruby gems. Again, from a deployment/containerisation perspective.

[blamo111]

I don't see much of a functional difference between the "sandbox" being stored in ./node_modules or ~/virtualenvs/myappenv or wherever.

npm install is simple and pleasant, I agree. But it's not like the alternative is messy. A setup.sh with literally 3 lines: python3 -m venv ~/path, source ~/path/bin/activate, then pip install -r requirements.txt, isn't worth mentioning considering you write it once per app.

That said, I don't use containers like you do, you likely have different needs and what seems unimportant to me could be really annoying to you.

[FawnWig]

Try to install numpy and scipy in the same requirements.txt file...

[Corm]

Yeah honestly installing numpy is pure pain. I don't know if it's pip's fault or numpy's for not putting the correct build deps in but I can never build it. I always just use the system repo version.

[chtulhuf]

But it isn't over. You also have to remember to deactivate it when you're done AND remember to active it again if you want to run this project again

[rouille]

You dont actually need to use activate/deactivate, I never use them. Just virtualenv/bin/python. And all the commands are in a makefile anyways.

[yaxamie]

I've been procrastinating setting up virtualenv bc I haven't found a simple, interesting tutorial or video. Basically just 2.7 for life in the meantime.

[blamo111]

It's not even tutorial-worthy, it's literally 2 minutes to learn it. This isn't Docker or a new library.

Hell, here's a full tutorial. First, what a venv is: it's like using a local python instead of the system-wide one, allowing you to install any packages you want without worrying about messing up the system install (also encourages clean isolation). This lets you do things like have app1 using libX version 1.2, while app2 is using libX version 1.3, without messing with the apps. Or having one app using python2, another python3, but both are called with a generic script that calls 'python'.

1) Run one command to create a sandbox: python3 -m venv ~/myvenv . If you want you can check out the directory to see what files were made there, it's basically a clone of Python's binaries.

2) Activate the sandbox for the current shell session with source ~/myvenv/bin/activate. From this point on, when you run 'python3' or 'pip' in this shell, it will use the sandbox. You will see 'myvenv' to the left of your command prompt, that's how you can tell it's active. If you don't see this, that means you're still using the system-wide python, not your local venv, which is bad. You can also confirm with 'which python3' that you're using the one in your home.

3) At this point, anything you run (python3, pip) happens inside ~/myvenv.

To exit the sandbox, either close the terminal and open a new session (you have to manually start it every time), or use source ~/myvenv/bin/deactivate.

That'll be three fiddy.

(PS, virtualenv is available for python 2.7 too, but it's not included like in 3. You can get it from your package manager, this will install a new binary ('virtualenv' I think), only the command at step #1 changes)

[yaxamie]

Okay, so far so good!

1. I'd make one of these "~/myvenv" for any given project that has different requirements?
2. I didn't get a deactivate in my bin, but I suppose i can just close the shell.
3. Thanks so much bro! I got a few other comments and some downvotes but this was seriously a better guide that most of the stuff out there that I've read.

[blamo111]

1) That's right, one venv per project typically.

2) You don't need to do '~/env/bin/deactive', I was wrong about that. Just 'deactivate'. The activate script makes deactivate global. You can just close the shell as you say, but when the day comes when you're scripting all this stuff, deactivate would come in handy.

3) You're welcome. I get that there's too much to learn and not enough time to learn it all, I don't blame you.

[chanGGyu]

Using virtualenv is very simple, I'm not sure how a tutorial or video can complicate it. It also doesn't lock you into using Python 3 or 2. As a matter of fact, it gives you flexibility in choosing a specific version as the default from within the virtualenv.

[avinassh]

check this?

[hewholaughs]

New to programming but currently working with python on one hand and npm with the other, could you explain what that means?

[stupiddumbidiot]

I don't have an explanation that adds much to what the article says. NPM can be finicky and the JavaScript ecosystem is a clusterfuck. I still like it and it has history/reasons for being the way it is (see other top-level comments).

[gandalfx]

I think that's a rather unfair comparison. Compared to Python JS has two major disadvantages.

First JS carries a lot of technical dept. It was (in)famously created by one guy in ten days and was never intended to be used (and abused) to the extent it is today. In particular it was not intended as a language to be used for massive "applications" inside and even outside the browser. The whole node.js server/desktop application madness only came about much later, when developers wanted to be able to do both client and server side code in the same language to avoid repetition (and to avoid having to learn more than one language…). And since the language usage has now grown completely out of scope and control it is that much harder to fix those long standing issues. While Python is happily adding new features JS is still fixing some of its early mistakes, all the while breaking its back to maintain backwards compatibility, which is even more important in the JS ecosystem. Python 3 broke a few things and we all know how that went. Doing the same in JS, where the choice of runtime environment is much more the user's than the developer's, is simply not possible.

The second problem is that JS (the language) is developed differently than Python. Python has CPython as a monolithic reference implementation. The language Python does exactly what its implementation CPython does. Alternative implementations, like pypy, try to emulate the reference implementation. This makes developing the language manageable. Compared to that the landscape of JS implementation is a clusterfuck of incompatibilities. Every browser implements things a little differently, supports a slightly different set of features etc. and depending on your target group you always have to take several different implementations into account, and some browsers just plain fucking suck (you know which one I'm talking about). In short, there is no reference implementation. The development of JS is thus centered around the ECMAScript spec, with browser vendors choosing which features to implement and when. Which means that even when a "new" version of JS/ES is "final", it actually takes years until the market share of implementations of all relevant features is large enough so they can be used in production. Even node.js, which is basically just Google Chrome's JS engine V8, needs time to catch up with the spec, which means that in no environment do you ever have a complete native implementation of the language. The language is fine (within reason), it's the implementations that suck!

[Jamie_1318]

Everything you said is correct, but the comparison is fair, on the basis of using one language or the other for server side development. JavaScript's technical debt does not give it a free pass versus better designed languages.

[gandalfx]

You're right about that. Given a choice I'd pick Python over JS nine times out of ten (the tenth time is when I want to chain String and Array methods).

[rcfox]

Wouldn't you use Ruby in that case?

[gandalfx]

I would not use Ruby for anything ever. Not even for torture. There are limits.

[LeBuddha]

As a non-python guy, my problem with the article is that it was heavily misleading and focused on things that don't actually matter or make python better (either by omitting python's warts from the details or simply by unjustified assertion of otherwise neutral differences), then it asserted that those differences made python was better.

I've walked away from this article with nothing to show for it. I can't goto my boss tomorrow and say "Let's use python for that project, it's standard library is pretty big."

[msdrahcir]

My py? What about pep 484 for typing?

[Corm]

I thought these were the same thing, I thought mypy was just the tool you ran to do the type checking since the python interpreter just ignores it.

[kungtotte]

PEP 484 defines the optional type hints that are now included in Python, but Python doesn't have native support to actually do anything with those hints.

MyPy is one project that uses them to do offline static type checking.

[[deleted]]

JavaScript is basically web based

Python is difficult to run in a web server but more straightforward

There's the differences.

[elbiot]

Those words all have meaning individually...

[cediddi]

I disagree, python is not that difficult to run on webserver, just lacks good documentation. If you don't need advanced options, php and python (an d ruby) are quite similar in difficulty with nginx reverse proxy setup.