Shell Speeds, Bash and PowerShell
-
I think if rather use node for things past Bash or powershell. By design I think it would be a better performer than Python.
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
What's beyond shell functionality? I don't think I've come to that point or had a need to?
Once you are writing anything extensive. Long scripts where you'd want to move past vi and whipping it up in an hour or two. Once you move from "quick couple things strung together" to "writing software to manage automation".
The ability to be a good shell basically guarantees you can't be good at automation. BASH and PS are both good examples of this. They try to do too much, and it encourages people to use them for too much. PS especially.
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
I think if rather use node for things past Bash or powershell. By design I think it would be a better performer than Python.
Not at all. First, Node seems fast because it's not a language, but a large framework. Python isn't really slower than Node, it might be faster in fact. But Node has a singular design purpose and that's not system automation. And if you use it for system automation, none of those performance perceptions apply and I think you'd be sad with how slow it is. In fact, Node can't thread last I knew, making it way, way slower than Python. One of the reasons we like Python for automation is that it has great performance. Plus it is easier to write and maintain. So layers of advantages.
Node is purpose built for making websites and basically nothing else. that doesn't mean it can't do other things, but it's designed totally around that use case. And scalling horizontally.
Python is already a shell when its REPL is enabled (IDLE) and has a higher performance core, doesn't use Prototyping, doesn't require objects, and is mostly focused on scripting as its core function making it basically the ideal automation language.
-
Python speed varies a lot by how you use it. Python has the ability to call C libraries, giving it a lot of performance in that way. Python can also run on .NET or Java, both of which are extremely fast.
-
I was basing that off of these points, which makes Node seem like the VERY clear winner.
https://da-14.com/blog/python-vs-nodejs-which-better-your-project
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
I was basing that off of these points, which makes Node seem like the VERY clear winner.
https://da-14.com/blog/python-vs-nodejs-which-better-your-project
Simple way to tell if something is meaningful... do they mention Node (not a language) or JavaScript (language.) If the mention Node, then they are talking about one specific huge framework on top of JavaScript - and just talking about building web apps. So their talk of scaling and performance doesn't apply to our conversation of automation here.
It's not apples to apples. JS and Python would be a direct comparison. You'll notice in the article that they mention how Python doesn't do some things natively but Node does... that's because Node IS the extension for those things for JS. JS doesn't do them either. So the are cheating by selecting a specific setup of JS to compete against a generic setup of Python.
-
If you are making a website, expect that Node will be way faster. If you are automating, assume Python will be.
-
If we look at the Python vs Node article and flip it on its head, we'd see the opposite.
Instead of assuming we want async calls (something automation can't use) for performance and scalability, we should assume that we want threading. Async is designed for server performance (something listening), threading is designed for processing and "calling out" from a client. Python threads easily, Node doesn't support it at all. Python can do async, it's just not native. Node is an async platform for JS.
So if we look at it from our purpose, Python has the huge advantage out of the gate whereas Node is missing a lot of the basics.
-
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
If we look at the Python vs Node article and flip it on its head, we'd see the opposite.
Instead of assuming we want async calls (something automation can't use) for performance and scalability, we should assume that we want threading. Async is designed for server performance (something listening), threading is designed for processing and "calling out" from a client. Python threads easily, Node doesn't support it at all. Python can do async, it's just not native. Node is an async platform for JS.
So if we look at it from our purpose, Python has the huge advantage out of the gate whereas Node is missing a lot of the basics.
Ah ha, I see exactly what you mean. Yeah that clears it up.
-
In reality, neither is a screaming fast language. It's just that they are both excellent at specific tasks. Python rocks at automation and scientific programming (but nothing beats R or Fortran for science.) Node rocks at stateless web apps. If speed alone were the concern, C would win, with Java right behind. And languages like Go being pretty high. But those types of languages tend to be very poor for automation writing.
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
I was basing that off of these points, which makes Node seem like the VERY clear winner.
https://da-14.com/blog/python-vs-nodejs-which-better-your-project
Written by javascripts developers - what do you expect?
I stopped reading right here "The main thing we want from a programming tool is performance."
If the main objective would be performance, developers would still work with assembler.The main thing you want is to cut the cost (time) of development, while having adequate performance.
-
@Pete-S said in Shell Speeds, Bash and PowerShell:
If the main objective would be performance, developers would still work with assembler.
The main thing you want is to cut the cost (time) of development, while having adequate performance.This is very true. In most cases, it is developer time, not code time, that we want to save. This is how Ruby rose to prominence while being dog slow (better now.) PHP as well.
-
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
@Pete-S said in Shell Speeds, Bash and PowerShell:
If the main objective would be performance, developers would still work with assembler.
The main thing you want is to cut the cost (time) of development, while having adequate performance.This is very true. In most cases, it is developer time, not code time, that we want to save. This is how Ruby rose to prominence while being dog slow (better now.) PHP as well.
Yes, it has been so from the beginning of time. This goes for almost every language under the sun.
C was for lazy guys who could accept the slow performance and huge memory overhead compared to assembler.
-
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
@Pete-S said in Shell Speeds, Bash and PowerShell:
If the main objective would be performance, developers would still work with assembler.
The main thing you want is to cut the cost (time) of development, while having adequate performance.This is very true. In most cases, it is developer time, not code time, that we want to save. This is how Ruby rose to prominence while being dog slow (better now.) PHP as well.
I enjoy PHP a lot.
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
@Pete-S said in Shell Speeds, Bash and PowerShell:
If the main objective would be performance, developers would still work with assembler.
The main thing you want is to cut the cost (time) of development, while having adequate performance.This is very true. In most cases, it is developer time, not code time, that we want to save. This is how Ruby rose to prominence while being dog slow (better now.) PHP as well.
I enjoy PHP a lot.
PHP is nice, and not too bad for automation. But I'd generally prefer Python or Ruby.
-
@Obsolesce said in Shell Speeds, Bash and PowerShell:
What's beyond shell functionality? I don't think I've come to that point or had a need to?
even simple stuff you can probably solve, to a point with awk and jq, are way easier to do in Python, and the more you need to do, the harder it gets to implement in simple scripting languages. These days, if there's something simple to do, I just use ansible, and for anything complex, I just go for python. Even if the task looks simple enough for bash, once you start getting into it, you find yourself wasting time on unneeded bashisms that are totally avoidable with a proper programming language.
And yes, I confess to even writing deep recursion scripts using bash when I was younger and less experienced.
-
@dyasny said in Shell Speeds, Bash and PowerShell:
once you start getting into it, you find yourself wasting time on unneeded bashisms that are totally avoidable with a proper programming language.
I just want a freaking array, dammit.
-
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
In reality, neither is a screaming fast language. It's just that they are both excellent at specific tasks. Python rocks at automation and scientific programming (but nothing beats R or Fortran for science.) Node rocks at stateless web apps. If speed alone were the concern, C would win, with Java right behind. And languages like Go being pretty high. But those types of languages tend to be very poor for automation writing.
Actually, Java isn't anywhere near C or C++, it's closer to Python, with all the JVM madness and tuning and lack of hardware awareness. Python is also pretty horrible at threading. This is the main reason Go is becoming so popular - it is exactly great at the stuff Python lacks in, especially threading.
-
@dyasny yeah, but it does threading at least. Better than nothing. I've done Python threading for this and for remote automation tasks, even bad threading is screaming fast because there is so much latency everywhere else.
-
@scottalanmiller said in Shell Speeds, Bash and PowerShell:
@dyasny yeah, but it does threading at least. Better than nothing. I've done Python threading for this and for remote automation tasks, even bad threading is screaming fast because there is so much latency everywhere else.
That, again, depends on what you are automating. Blazing fast distributed systems are a reality, and those are usually not written in Python (yes Openstack is mostly Python, but we all know just what a huge pile of awful it is)
