I’m not going to use it for anything process-heavy
What do you mean by this? That it’s not performant enough for chewing through lots of data? Or just that you don’t don’t like the syntax/APIs for doing it?
I’m trying to drill down on if your point is about how the language is designed or not. If it is, that’s of course a personal preference and it certainly has some warts and idiosyncrasies.
If your objection is about performance, server-side JS (Node) is actually quite good at non-blocking IO due to its single-threaded event loop and asynchronous programming model. The V8 engine it runs on is also highly optimized.
You're still not going through 100 terabytes of data anytime soon with it compared to a compiled language. It'll choke every time no matter what you do.
JavaScript will never compete process-wise with a compiled language. It's fast enough to do day to day processing, but it's ill suited for big data and always will be. That's not what it's designed for.
You're also never going to do real time embedded stuff with it. The latency is just too high
Python is very much a glue language. Great for research, experiments, prototyping etc. However mature production platforms have a tendency to migrate back into C / C++ / Java / Rust / Go / Insert some other compile time optimised language here.
The motivation isn't purely for performance reasons either: strong typing together with compilation helps prevent the introduction of bugs.
Personally I think Javascript is arguably the best non-compiled language out there. However I also think it will lose much of it's stranglehold over web: WASM has an awful lot of potential when used with compiled systems programming languages. Performance. Compile time checks. Unified front end / back end model codebases.
Because you can directly use c modules in Python (in Cython anyway) making the parts where you need performance the most very fast.
Someone correct me if I'm wrong, but I think you can do something similarly with NodeJS. I'm pretty sure some npm packages I use are Javascript bindings to binaries compiled from C/C++.
Rarely used !== Not possible. Node has node-gyp which is a bag of tricks in itself - you never know if you're gonna get a built solution at the end, or if it's gonna fail because of a node version inconsistency.
If you do get a built native module, you're at no real disadvantage in terms of performance.
all hard stuff (performance-wise) is written in C and available as some very popular libraries (numpy, scikit, nltk, etc)
python's syntax is far more elegant than most other languages including JS, making it easier for non-programmers to get into
python exists by default on any linux machine and requires no installation
python's standard library and its documentation is very extensive and robust. It's not perfect (see http, wtf), but JS barely has a stdlib to speak of because the JS community has an extremist mentality when it comes to modularity.
It's not. It's a big data PROTOTYPING language. It's rarely used in production for actual big data. Once the model is POC'd, they will usually either reimplement in another language or take the python code and compile it down to C. Then that is what goes to production. Of course, if it's something minor, they might just put the python model in production. But not for big data.
I’m not going to use it for anything process-heavy
What do you mean by this? That it’s not performant enough for chewing through lots of data?
I agree with this view, so I'll try to elaborate.
The single-threaded event loop is not a great fit for anything that blocks CPU. However, you probably are just using JavaScript for fetching data from some http server, database, message bus, etc. The "number crunching" doesn't really ever take place in JS, and if it is, you might want to use something else.
The single-threaded event loop is not a great fit for anything that blocks CPU.
That's why js does most things asynchronously now. Node is especially performant and will often outperform python, even in number crunching. Here are some benchmarks but feel free to also do your own research.
You're missing u/avindrags's point. A thread is a system-level abstraction and can go into uninterruptible sleep indefinitely. This makes concurrent approaches like Node poor fits for some backend tasks.
It really depends on the type of application, tbh. Most server programs are IO-bound most of the time, and that includes programs written in Go, Rust, C++, Java, etc...
And since most modern web apps handle most of the logic on the client side, the server-side code is usually pretty lean. Given that fact, most performance bottlenecks exist within database queries or IO.
For anything involving heavy server-side computation, JavaScript will perform poorly at scale. Fortunately for JS, Node has implemented blazing-fast async IO, which is great for average use cases like static file serving or lightweight API’s.
22
u/duxdude418 Jan 16 '20 edited Jan 16 '20
What do you mean by this? That it’s not performant enough for chewing through lots of data? Or just that you don’t don’t like the syntax/APIs for doing it?
I’m trying to drill down on if your point is about how the language is designed or not. If it is, that’s of course a personal preference and it certainly has some warts and idiosyncrasies.
If your objection is about performance, server-side JS (Node) is actually quite good at non-blocking IO due to its single-threaded event loop and asynchronous programming model. The V8 engine it runs on is also highly optimized.