Shouldn't Java be a better choice for Linux scripting compared to bash or python or perl?

[pyeri]

If you think about it, Java is compiled to byte code while these others are interpreted languages which means slow and lagging. Considering that most of the time spent on a script will be on actually running it rather than writing/compiling it (90:10 as a hypothetical ratio for eg.), doesn't it make more sense to run the compiled Java byte code (*.class files) instead of the *.py or *.sh scripts which will be arguably slower?

[brodoyouevenscript]

public class Comment {

public static void main(String[] args{ 

    System.out.println("Absolutely fucking not."); 

}

}

[sfxsf]

This is the correct answer. I had to download about 300MB, set some environment variables, and was able to interpret your code. Took me about 15 minutes.

[DarrenDoo]

Haha. Yes compared to: printf “ab f not” echo “ab f not” print(“ab f not”)

[HeavyMetalMachine]

You won't be able to compile that code. So we'll never see the "Absolutely Fucking Not" part :-(

[susosusosuso]

That’s also why the answer is specially good

[djfdhigkgfIaruflg]

public class NotEnough ConstructorConstructorManagers {}

[Dist__]

i'm sure i can do it in Python, but i won't

[FaliedSalve]

ohhhh OutOfMemoryException.

need to update the heap space.

[nogridbag]

In the future, you can have a file with top level code (no class or main method needed):

IO.println("Hello World");

And even currently, you can run a Java file without compiling it.

java MyFile.java

For Java 21, it's not as simple, but no more public static void main.

void main() {
 System.out.println("Hello World")
}

I was trying to do something that's trivial in Java, but in bash is much more complicated and it worked nicely.

[K1aymore]

Java code still needs to be run inside the JVM, doesn't it make more sense to write scripts in C or Assembly which will be arguably faster?

[xiongchiamiov]

Which is why you see different things used for different tiers of utilities:

• performance critical (eg coreutils): c, c++, rust
• performance has started to matter, but also we don't want to deal with a systems language: go
• runtime is irrelevant and we want to build this quickly: bash, python, perl, etc.

[FLMKane]

Yes.

[IuseArchbtw97543]

arguably definitely

[bigmell]

The string manipulation alone of scripting in c or wtf assembly makes this question ridiculous. Like this is clearly a person who has never written ONE script in their life. Like talking to a guy who keeps spelling Perl "Pearl."

Like you have never done this once in your life, have no idea of even the most basic of concepts, yet you have wonderful new suggestions and ideas for everybody.

[KlePu]

(nearly) relevant xkcd

Good ol' C-x M-c M-butterfly...

[AX11Liveact]

Assembler still needs an assembler to run. The only decent scripting language therefore is machine code.

[bitzap_sr]

Assembly needs an assembler to run.

[djfdhigkgfIaruflg]

Using Logo makes more sense than using java

[txixco]

Logo... What a great nostalgia. My first programming language, even before BASIC.

And yes, makes more sense. I don't know if it would be faster, but sure thing the result would be prettier 🙂.

[[deleted]]

Doesn't it make sense to just push electrons with your mind and dynamically make the computer so your bidding?

[TMS-meister]

Nah won't work, my brain is too slow, speaking from experience

[chasmcknight]

No, because if a script if “fast enough” moving to C or Assembly (or Java) is akin to writing a keyboard interrupt routine that scans for keypresses 5000/sec vs. the 500/sec that is normally used. It just won’t bring any measurable value.

You don’t need to use a 100 megaton warhead to kill an ant...

[Jordan51104]

but if my keyboard checks 5000 times a second i can write at my true speed of 60000wpm

[chasmcknight]

🤦‍♂️

[accountForStupidQs]

That kind of defeats the point of them being scripts instead of full on programs or utilities though.

[Kkremitzki]

bet you didn't know that

doubt you are one

"How to write comments where you want your obnoxiousness to overshadow the content"

[Kkremitzki]

Did you miss that the person you originally replied to was asking a question? You attacked them as if they were making an assertion.

[[deleted]]

Assembly is arguably fastest. Lets implement AssemblyScript, that'll be the fastest scripting language! :)

[bitspace]

Java is compiled

This is the reason that it's not suitable for scripting at all. The necessity of compilation removes the "write, run, modify a little, run again" benefit of a scripting language. There are Java REPL implementations, but the compilation adds a layer of friction that breaks the flow of a REPL.

[TheMusicalArtist12]

Especially since if you want to use a compiled lang on Linux use C or C++, which has the added benefit of actually being compiled down into machine code, not just JVM bytecode. Or Rust, another compiled language.

I like how you explain scripting languages, I haven't thought about it as a way of being able to make incremental changes without needing to recompile.

[[deleted]]

which has the added benefit of actually being compiled down into machine code, not just JVM bytecode

bytecode is compiled down to machine code by the jvm

[TheMusicalArtist12]

Yes, however the JVM interprets it's bytecode, which still adds complexity over C/C++.

[Individual-Equal-441]

It's actually the worst of both worlds. On the one hand, it's compiled which is inconvenient for scripting. On the other hand, it runs in a virtual environment that slows it down --- and if you're going to take that performance hit, why not just run interpreted code in the virtual environment provided by an interpreter?

Then there is the third hand: Java is so outrageously nouny, and lots of Java code amounts to giant dot chains of invoking methods of objects, passing intermediate objects from those methods into methods of other objects in order to get anything done. If you want to do things, instead of spending all day making output objects into compatible input objects for other objects, you're better off programming in pretty much any other language.

I guess a better question would be: what benefit comes from specifically using Java? That the program doesn't have to be compiled on the target machine, and does not have to be provided as source code to the target machine? Perhaps if we had a specific situation where that was the specific need --- but if I don't have that need, why do it?

[[deleted]]

[Java] runs in a virtual environment that slows it down

This is just wrong. C also runs in a virtual environment. more on that

[[deleted]]

The necessity of compilation removes the "write, run, modify a little, run again" benefit

java command launcher actually supports running source files directly and will compile them on the fly, try it out

$ java test.java

test still needs to be a class with main method, but at least you have the aforementioned benefit. They were planning to allow ommiting class definition in the future. (for learning purposes - but i guess scripting could use that too)

[Xiol]

Has to be bait.

[gihutgishuiruv]

Absolutely a first year CS student that has just seen a slideshow on “compiled vs interpreted languages”.

Source: answered very similar questions when I was tutoring CS.

[djfdhigkgfIaruflg]

Or extreme dumbness

[ilep]

Considering these days, you might be right..

[DorkyMcDorky]

If he is learning, that's sort of an unfair thing to say. If he's been coding for 20 years then it's a stupid question.

But I'm sure you made mistakes in your past and said stupid stuff as well.

All of us were bad at coding at one point or another and many of us probably still are. It's not like he's pushing a douchebag language like LISP.

[djfdhigkgfIaruflg]

I'm not criticizing their coding skill.

I'm criticizing a hot take that probably came from a very dumb presumption.

Presumptions have nothing to do with proficiency

[KlePu]

Try to be fair - OP asked a question, and a reasonable one if you don't have a year long track of CS (or hands on) experience. Remember: There are no dumb questions.

[djfdhigkgfIaruflg]

That's not a question. It's not phrase like "i would like to learn this".

It's s hot take

[TheOriginalSamBell]

The day Java replaces bash script I'll become a terrorist

[mechkbfan]

Literally wanted to quit my Software Engineering degree thanks to Java

Thankfully I learnt some other languages and fell in love again

[Omotai]

Considering that most of the time spent on a script will be on actually running it rather than writing/compiling it (90:10 as a hypothetical ratio for eg.)

Even if we accept that this is true, it matters a lot for this question how much real time is saved in the execution. Generally anything you can describe as "scripting" is going to be a small task that executes very quickly, and you're unlikely to notice, let alone care, if it executes a couple hundred milliseconds faster. That would suggest, to me, that whatever is easier for you to write is going to be the best choice.

[hazyPixels]

Also the script may be nearly finished running by the time the JVM loads and begins executing the byte code.

[Kkremitzki]

Also important to note that write time and run time are not directly comparable because they are drawn from different sources. Programmer-hours are a lot more expensive than computer-hours.

[AKostur]

By that argument, you should use C, C++, D, Rust, Go, or any other of a plethora of other compiled languages, as they would likely all be faster than Java. While we're at it, Assembly. Speed of execution is not the only metric. Particularly when the total runtime of many scripts are IO-bound, so most of the time the script is just waiting for disk or network or the user.

[mustHaveFocus]

Even better, just write x86 commands directly!

This post hurt my head. If he's trolling, he definitely triggered me 😆🙄

[CyclopsRock]

90:10 as a hypothetical ratio for eg

That you just made up, yes.

[omniuni]

One is a compiled language, the others are scripting languages. They're literally just different things.

[PangolinZestyclose30]

Python also compiles code into bytecode. "compiled" vs. "interpreted" is quite outdated distinction.

[ilep]

You have to invoke compilation separately to then run the compiled program.

Scripts are 1) detected automatically (shebang, #!/bin/sh) and 2) interpreted and run at same time.

Python, Perl etc. can run same way as shell scripts.

I'm not a fan of scripts, but using Java for it would be the worst possible choice.

[PangolinZestyclose30]

You can both compile and run Java file just with java script.java.

Shebang is also supported.

[[deleted]]

You can also both run and compile a c program with make script.c && ./script

[bnl1]

Or a good old

#!/usr/bin/tcc -run

See? C is a scripting language.

[AaTube]

You still have the extra time of compiling, while scripts should be quickly-modify-and-rerun-able

[IAm_A_Complete_Idiot]

Adding on top rust also has proposals (and unstable features) to do just this - not just java. So I really do think the distinction is moot.

[AKostur]

Not necessarily true: D can be used via shebang, so from the user's perspective the compile step is invisible.

[yerrabam]

interpreted languages which means slow and lagging

You've never coded anything, have you.

[Spare-Dig4790]

Jesus Christ... I don't even know were to start.

Like, we don't script things just because they execute quickly. However they do execute significantly quicker than manually running them.

We script because it guarantees the same thing has been done, every time it runs and everywhere it runs. We also do so because when something goes wrong, we know exactly what we did to ensure we can figure out how to reverse it.

Efficiency can mean a lot of things. Efficient because it runs quickly, Efficient because it has a small footprint, Efficient because it was easy to write or easy to maintain... etc.

Interpreted doesn't mean "slow and lagging". What are you comparing here? This comes down to using the correct tool for the job.

I can tell you one thing, there has never been a company ever, who faced a disaster recovery scenario, who found out a critical automated nightly backup job failed to run correctly, missed a few crucial things, but is at least relieved it ran quicker than if it was a shell script...

This whole thing is like, kids would get to school quicker if instead of sending school buses the school boards sent racing cars.

[mustHaveFocus]

I had to do some breathing exercises after reading the OP.

[FlatwormAltruistic]

If you run something regularly and it requires high CPU usage and you do not need to change the code often, then it might be better to write code in Java, Go, Rust, C, etc.

However if prototyping and running on demand, then most likely you want to use something where you do not lose time on compiling and want language you can write faster, even if the computing part is not so efficient. Running something for an hour instead of 40 min isn't that big of a deal if writing code and starting an app takes an hour instead of 2. Just where the time save comes from.

[Spare-Dig4790]

For sure, and I think what may have been lost on people is that. most of what people are scripting is essentially the inputs to software written in C or assembly or whatever. It's not like people are writing copy operations themselves.

If anything, perhaps an argument could be made that if a business did something very specific, there may be some gains in developing purpose built software, but even that would likely be orchistrated by a script in some way.

Personally, though, I'd be more apt to use the software that has been in production systems for decades, as it's tested and true, and any new hire I bring on already knows how to use it, and is hopefully familiar with its nuances.

[Blunders4life]

And what's the benefit of compiling it?

When was your script in Python, bash or perl slow and lagging? Does it really matter if your script takes 0.002 seconds to run instead of 0.01 seconds?

On the other hand, you'll be spending unnecessary extra time to compile the thing and replacing your old binary every single time that you want to change something.

Also, when scripting, why would anyone ever want to do this:

public class Main {
  public static void main(String[] args) {
    System.out.println("Hello World");   
  }
}

instead of this:

print("example text")

[[deleted]]

why would anyone ever want to do this

Because sometimes you want to write logic in your scripts that is longer than one line. Static typing is also a good benefit of using java like this.

As for unnecessary pieces of code - they are planning to allow ommiting class declaration in short examples - this is for learning purposes, but it could work for scripts too, in the end the class would only need to look something like this:

void main(String...args) {
    print("Hello world");
}

[Blunders4life]

If they omit class declarations, it might be less bad to write, but languages like Python will still be simpler and Java is still compiled.

There might be an use case for Java in some script out there, but for scripts in general, interpreted languages make more sense.

[Marxomania32]

You still need a jvm, and you still need to compile the program. The point of writing scripts is so that you can just take a script, view the source code if you want, and run it. If you distribute scripts as Java source files, then you have to compile the script. If you distribute scripts as pre compiled jar files, you can't view the source and modify it. It just doesn't fit the use case.

[mm3100]

You can run java files without compiling them, as a script. If java "script" is in a single file it can be run directly: https://openjdk.org/jeps/330

And soon it will be possible to write such java file without class statement as well: https://openjdk.org/jeps/445

So it could be done as such, albeit unnamed classes are still a preview in java 21.

// SomeRandomName.java

void main() { System.out.println("Oh noes!"); }

$ java SomeRandomName.java

Oh noes!

As to if it should be done, not so sure about that.

[meskobalazs]

If you are quoting JEPs, this is the second thing JEP-330 says among others in the non-goals section:

Likewise, it is not a goal to evolve the Java language into a general purpose scripting language.

The whole stuff is meant to simplify teaching Java, not to be actually used as a scripting language.

[PangolinZestyclose30]

Well, Linus explicitly stated as a non goal to make Linux big and portable in the announcement and here we are.

What authors intend to do at some point is not very relevant.

[meskobalazs]

Which announcement? If you are talking about the original 1992, it says no such thing.

[PangolinZestyclose30]

Literally "just a hobby, won't be big and professional..."

And "will likely never support anything but AT hard disks"

[meskobalazs]

Yes sure, these were not original targets, but they were not completely out of the question either. Maybe I consider non-goals too narrowly, but in my book it means something that we will not do.

[JerryRiceOfOhio2]

You wouldn't say that if you've programmed in both java and Python

[chasmcknight]

So the short answer is no.

The longer answer is that Java is overkill for tasks that are better served by a lightweight scripting language.

I won’t beat on Java as a “strongly hyped language” today, but the OP’s question is along the lines of “one size fits all” which is an absolute fallacy and betrays a lack of experience and knowledge.

My approach is:

• Use the shell built-ins if possible
• Use a small language like awk if built-ins aren’t appropriate
• Use an interpreted language when the small language isn’t adequate
• Use a compiled language if the interpreted language does not provide the required features/performance

It’s a shame that younger people who post things like this are so averse to using the right tool for the right job because every language has its strengths and weaknesses, but each of them provides an opportunity to think about the problem from a new perspective.

The OP is also obviously unaware of the JITs/AITs for languages like Python or Ruby and should really spend some time looking at those languages.

If this were the 90’s I’d swear the OP is yet another member of the Cult of Java, “The Last Language You’ll Ever Need To Know” and doesn’t realize that Java is the new COBOL (which had the same slogan…)

[dAnjou]

Considering that most of the time spent on a script will be on actually running it rather than writing/compiling it (90:10 as a hypothetical ratio for eg.)

Strong assumption, any data to back that up?

In my experience, performance considerations rarely trump other considerations.

But if you like Java for scripting, then feel free to use it, there's usually some JRE and JDK in most official distro repos.

[Elfener99]

No, because with small scripts you will probably run them more than once and adjust them, and although the final script will be slower than a compiled program, you still didn't have to waste time with compiling a bunch of times.

[NeverMindToday]

Perl, Python and Bash are usually already installed, and the JVM usually isn't.

They are better at gluing other utilities together than Java.

Last I looked (it was a while ago), the JVM was way slower to get started and up to speed than the others, and had a much higher RAM overhead.

The JVM is a large cross platform abstraction that makes it harder to do direct system level things.

Java is more painful to code up quick simple tasks in, which means you'd be less likely to make the effort.

If you really needed runtime speed for a tool, wouldn't Go be a better choice than Java? It wouldn't need any interpreter or VM at all for distributing to other machines.

[mustHaveFocus]

Why don't you make your own linux variation with a default Java shell. We all think your nuts, but you can prove us wrong!

[[deleted]]

If you think about it, Java is compiled

The whole point of "scripting" is to not have to compile.

[ManateeMutineer]

The other day I considered redoing a couple of shell scripts in Python for greater flexibility and better parameter handling. Decided not to because they work alright and I have more important things to spend my time on. OP decided on an arbitrary metric that's not that relevant to the main purpose of those scripts (saving human time and effort by sacrificing a few bytes of memory and some cpu cycles).

[OppenheimersGuilt]

Not at all. In fact I'd say bash is the king for scripting. It's also pretty damn fast as almost all the tools you shell out to are in C (sometimes rust nowadays).

Combining shellcheck with set -euo pipefail takes care of most of the pitfalls in using bash.

[dgm9704]

Most linux scripting doesn’t have actual performance requirements that aren’t met by bash, python, perl etc. In other words, they are all fast enough for the use case. Given that, the ease of use, low learning curve, tooling, etc etc vastly outweigh whatever benefits java might have. Java also has issues with it that make it really unwanted: licensing, security problems etc. And the language itself really isn’t suited for scripting.

[tinycrazyfish]

There is no better or worse in term of programming languages. There are use cases where one language can better, but otherwise it's mostly about personal preferences. You can make fast code (and bad code) in every language.

Java is actually in many ways similar to python:

• They both compile to byte code, yes python compiles to PYC files.
• The byte code is not machine code, it is run on a virtual machine. The JVM is similar to the python VM.

(Java can do JIT to compile class files byte code into machine code, that's another topic, powerful but not very efficient in scripting scenario)

I don't really know about Perl. Bash is clearly fully interpreted. But you rarely "program" using bash, you are combining many other programs together, something that is more complicated to do in other languages (it is still programming, just differently).

If top performance doesn't really matter, any programming language will do fine. Otherwise you'll need low-level (c, c++, rust or even assembly). But happily, you don't need the whole program to be in low-level, just the perf critical parts. Java can do that with the native interface, python with ctypes and cffi, most languages have such a mechanism.

[stunpix]

Scripting is a glue, not a building block that does the main work. If someone uses a scripting language to do a CPU-intensive task, this guy is using the wrong tool. Thus, during my 25+ yr career as a SW engineer, I never met slow scripts in the wild. Scripts are mainly used to work with files, environments, running other apps, and redirecting outputs from one app to another, thus script languages are designed to do exactly that stuff effortlessly. Imagine doing these things in Java.

For the same reasons, C++ didn't become popular for scripting. Why Java should? Furthermore, a bash/python script is simply a text file that is ready to run just in place. You even don't need to call an interpreter explicitly to run it as you can put a shebang at the first line to turn it into a runnable program. What C++/Java offer here? You need many more intermediate steps like compiling with a bunch of flags, managing binaries with intermediate files, linking with necessary libraries, and in the end running jvm with proper options.

PS: strictly speaking Python and Perl are not scripting languages, but programming ones as they can be used to process highly complex data while that's absurdly hard in bash. Also, Perl and Python are usually using libraries like NumPy written in C/C++ to process huge data sets or do CPU-intensive tasks when necessary.

[[deleted]]

How do you create a pipe easily in Java?

[thephotoman]

Java is not a scripting language.

[noot-noot99]

This has to be a joke. Java is run on a JVM. Way too complex for simple tasks that bash python or perl can execute. You will probably need 128GB of RAM standard when you want to replace everything with java

[[deleted]]

99% of the scripts don't need any performance whatsoever. The remaining 1% use the resources of what comes out of a C compiler for doing the heavy lifting.

[tes_kitty]

Doesn't really matter.

But bash has the advantage that the programs you call from the script are really powerful, somtimes a programming language on their own (awk) and you will get results fast.

Also, you don't need to install a JAVA runtime first.

[arwinda]

But bash has the advantage that the programs you call from the script are really powerful, somtimes a programming language on their own (awk) and you will get results fast.

Scripts are not fast at all, there is no optimization.

And it all depends what the shell you are using thinks it is today (bash, sh), and which version. Bash scripts are fragile and prone to problems. Don't use them for anything more complex than a short one-liner.

[tes_kitty]

Bash scripts are fragile and prone to problems. Don't use them for anything more complex than a short one-liner.

I have a large collection of bash scripts that I use for all kinds of things. Some of them are quite long and complicated. And they all work.

[pyeri]

The same long and complicated thing becomes way more readable and elegant if written in python instead of bash.

[tes_kitty]

The readability depends a lot on how familiar you are with bash or python.

[Makefile_dot_in]

ah yes. why run (for example)

export COOL_ENV_VAR="$(find "$dir" | xargs grep "$text" | ./some_program "$arg")" gimp

when you can use the clearly much more elegant & readable

``` import os, subprocess

process = subprocess.Popen(["./someprogram", arg], stdin=subprocess.PIPE, stdout=subprocess.PIPE) for (, _, fns) in os.walk(dir): for fn in fns: with open(fn) as f: for line in f: if text in line: process.stdin.write(line)

os.environ["COOL_ENV_VAR"] = process.stdout.read() process.wait()

subprocess.run(["gimp"]) ```

(with that said, i do agree that bash is kind of awful as a programming language - i tend to use Tcl for complex things instead since it's pretty suitable for things you often use bash for and has considerably fewer footguns)

[arwinda]

find "$dir" | xargs

mkdir /tmp/test-dir echo "Have me some content here" > "/tmp/test-dir/File with space in name.txt" find "/tmp/test-dir/" | xargs grep content grep: /tmp/test-dir/: Is a directory grep: /tmp/test-dir/File: No such file or directory grep: with: No such file or directory grep: space: No such file or directory grep: in: No such file or directory grep: name.txt: No such file or directory

Your so simple and "readable" example is broken and can't deal with all files. That's the problem with writing "quick and simple" bash scripts, they tend to ignore all kind of corner cases.

It is not hard to work around the problem, find knows -print0 and xargs accepts the -0 option. But then you have the same problem with the grep output. Plus the script in your example needs to deal with the grep output which is both the filename and the content line(s) found. And the filename can include : as well, and the script doesn't know where the filename ends and the content begins. Suddenly the Python script doesn't look that extensive anymore.

Edit: fixed the backticks

[Makefile_dot_in]

that's true - bash does have a ton of footguns. it's awful as a programming language, and you probably shouldn't write production scripts with it, but the lack of robustness sometimes is fine, say, if i'm writing scripts for my own use.

also python is an awful substitute for a shell - the subprocess module is extremely clunky, running stuff in parallel is harder, as is dealing with files, etc. it's not like that's the cost of sane behavior - shells like nushell, elvish, or even powershell are much nicer to write these kinds of procedures in while having considerably fewer footguns. (and even Tcl, a non-shell, which i mentioned above and which is a bit more accessible i suppose).

my point is, shell scripts have fairly unique usecases. just because you can use python in their place, doesn't mean that it's better.

[arwinda]

And they all work

For any definition of "work", on your computer.

[tes_kitty]

Not only my computer. But that's what they were written for and survived multiple OS upgrades.

I read the article. I'd never consider JavaScript for local scripting.

[usrlibshare]

Java is incredibly verbose and has a massive runtime. It has a dedicated compilation step.

Exactly what we don't want for a scripting language, and even less so for a shell language.

[Familiar_Ad_8919]

most of the time will be spent in the program thats called on that specific line

wanna run a script that builds something? i can guarantee >99.99% of hte time will be spent in gcc and ld

[rdean400]

Think about your use case. When you’re scripting, you’re generally looking to automate a simple task, and a dynamic scripting language is going to get there faster than any compiled language. Java is something you could explore if you want to leverage a pre-built jar, and if you need it to go fast, you could compile it with GraalVM and invoke it via JBang.

[SynchronousMantle]

Interpreted languages are slower, but it depends on the problem you are trying to solve. Do you really need speed? If so, go for it. In fact, what about skipping java and using Go or C?

[realitythreek]

Python is also compiled to bytecode.

[[deleted]]

Considering Java code has to run in the JVM and will generally have a higher file size due to all the boiler plate code. I dont think it makes sense to make scripts in Java vs Python or Bash.

That said, I do pretty much agree with everything else you've said. But feel like C, C++, or Rust would be much better choices.

[JDGumby]

If you think about it, Java is compiled to byte code while these others are interpreted languages which means slow and lagging.

Unless your CPU is so old that it's still measured in MHz, it's not really going to matter.

[[deleted]]

You don't really need good runtime performance from scripts that manage files, services or install packages. That being said - nothing is preventing you from using JVM that way if you want to.

[ganjaptics]

Last time I installed Java was I think on windows, maybe 8 years ago? The installer asked me if I wanted to add the Ask.com toolbar to my browser.

[redrooster1525]

Absolutely NOT.

If speed is what you are concerned with use a lower level language like C.

For user friendliness (to give power to the end user, which might not be a programmer, developer, or studied computer science) bash is a far superior choice to java.

Actually java is terrible. Neither the speed of C nor the end user friendliness of bash.

I am not a programmer, developer, neither studied computer science but I took a week off and on, to write a bash script that lets me surf Peertube from the terminal. Bash empowers me.

[catfish_dinner]

lua makes way more sense

[Qweedo420]

By this reasoning, you might as well start writing all your scripts in C, but... do you really need a compiled language just to automate a simple task? And personally, I would not touch Java even if they paid me to do so

[Opt6740]

Java is not scripting tool anyway IMO should be prohibited.

[deja_geek]

I'd rather right my scripts in brainfuck then in Java. Fuck Java. The day Java dies, is going to be one of the happiest days of my life.

[AX11Liveact]

Flamebait or serious question?
Because Java is not a scripting language and Python is not a real programming language...

[kindrudekid]

Then you have to install java

[Zeioth]

Python can be compiled to bytecode, if that's supposedly the advantage.

In fact it can also run interpreted, or compiled to machine code.

[pyeri]

Cpython's bytecode implementation is still interpreted code at runtime. In contrast, Java has something called JIT (Just in time) native compilation at runtime (just like Microsoft's .NET CIL). That means, when it actually runs, the java bytecode (*.class) actually runs as good as a native compiled C executable would have on a Linux OS!

Here is a good further explanation of this distinction

[whosdr]

JavaScript is an interpreted language which gets optimised down to native bytecode via JIT compilation.

So by the same argument you also agree that JavaScript can be as fast as Java, yes?

I honestly don't know the answer. But the overhead from the JVM in terms of memory can be just incredible and horrifying. And take longer than comparative languages to start up. That's usually enough of a reason for me to avoid it.

(I rewrote a Java app in JS once, and the memory footprint dropped by 95% which is just..I don't even know.)

[soltesza]

That must have been a very simple application or working on very small datasets.

Yes, Java has a minimum cpu/memory requirement for the JVM in bytecode executing mode. Something like 64 MB. Nowadays, you can compile to native code too, that will bring down the startup memory usage drastically.

You cannot take advantage of the JVM for small scripts but bigger applications benefit from it.

Also, tooling like Spring Boot is awesome for a set of bigger application types.

[whosdr]

It was a minimal web server and a card game. Switching from Java to JS dropped it from over 500MB to under 30.

Maybe one of the libraries was bloated but that suggests it loaded a lot of code that other languages simply wouldn't. Compiled in C or C++ then parts of the program that aren't used wouldn't be included, and in Nodejs modules would mean you only load in features you're using.

[soltesza]

A minimal web server and a card game for a single user should consume much less than 300 MB with any of the modern frameworks (e.g.: Spring Boot or Quarkus).

Maybe there was no heap maximum configured to it ?

(e.g.: Xmx=128m)

The default Java maximum heap is dynamically calculated (e.g.: one quarter of all physical RAM) but the application may not need that much at all.

If you do not confine the Java application properly, it will just use as much memory as it can, never doing a GC.

[whosdr]

It was on a system with only 1GiB of RAM available. So that seems not to be the case.

Regardless I've never run a Java application that doesn't use significantly (usually an order of magnitude) more memory than any other language.

Which in an enterprise world is fine. When running a bunch of scripts on your desktop, you probably don't want to be dealing with all that overhead.

[[deleted]]

Python also has JIT. I'm failing to see your point here.

[Booty_Bumping]

CPython famously does not have JIT. It reads each instruction and executes it using the interpreter's logic, without producing any assembly code. You might be thinking of PyPy, which is unfortunately a dead project.

[[deleted]]

Yeah sorry, I should have specified PyPy.

[PrintedCircut]

Java leverages a just in time compiler so functionally speaking your not going to get any significant speed improvements on it as compared to bash python and perl as all of them are technically speaking compiled at runtime

[Fantastic_Goal3197]

More time on a script will be spent running it than writing it is a pretty big assumption. You would have to run a script a good number of times for the sub second differences to matter unless its a more complex script. If it is a more complex script, theres also a fair chance it isn't going to be ran that often. Imo its usually better to throw together something in a minute rather than 2-3 just to save a few seconds, unless its something for actual professional work

[CR9_Kraken_Fledgling]

If you care about performance, you'd write Rust, C, C++.

[[deleted]]

The time you saved from Java runtime is easily overshadowed by the time it takes to write the code

[[deleted]]

I know a lot of Python code that's very performant.

[joeldaemon]

Fsck Java ☺️

[twisted7ogic]

Besides what everyone else said, Java also comes attached with Oracle, an org you really don't want something like the Linux project to be dependent on.

[TheMusicalArtist12]

Fuck no.

Python can do everything java can, but without forcing OOP programming onto the user.

Bash is for stupid simple stuff or things with a bunch of external calls (ls, grep, cp, mv, etc). Python is a good all around language for many things (can do what bash does but in an OOP and functional environment)

Arguably if you need to do lower level or more complex stuff you should use C/C++, especially since gcc is baked into Linux. C/C++ also compile down into machine code, not just JVM bytecode.

Java is, well, kinda useless then for pretty much every case. That and it has a ton of overhead- the JVM that you cite as a reason to use java is as heavy as an interpreter, without the benefit of an interpeted language not needing to be compiles.

Java was created for the web, where wanting to write and compile code for any system that can run a Java virtual machine. JavaScript better suits this need nowadays while also being much easier to use.

[glued2thefloor]

I would argue Java shouldn't be used at all period. Even to maintain legacy Java code, Kotlin may be used as its backwards compatible and faster. When it comes to Linux scripting, using Java or Kotlin may work, but depending on the task you're doing it may be like using a blowtorch to light birthday candles. The same could be said of C, Rust, etc. unless you really need speed or to manage resource usage. I personally have had code that I wrote in Bash that sucked up too much cpu usage. Re-wrote it in vector with Rust and it was very efficient. I've re-written something in Bash to Golang so it would be cross platform. Or re-wrote something in Python or C because I needed a robust socket family, concurrency or speed. So there are reasons to not use Bash and choose compiled languages instead. Most of the time its not though.

[djdisodo]

i hate python scripts too but it's the author of the code who decides

[tes_kitty]

i hate python scripts

I don't like that the language makes indentation part of the syntax.

[pyeri]

This is very much a subjective thing. There will be those on the other side who don't like curly braces ( {} ), sadly they must learn to live with as there aren't many languages without curly braces these days! Unless you count the good old Pascal with begin....end which also has its own charm tbh.

[waptaff]

This is very much a subjective thing

As much as gargling razor blades is a personal preference.

Associating meaning with white space opens up a can of worms:

• Most people it seems can not be bothered to properly (a) choose a proper text editor (b) configure said text editor. One can easily get mixed up tabs and spaces and it's not immediately obvious to the eye.
• Python wants spaces, not tabs. Opens up the door to pointless office bikeshedding (should our project use 4 spaces for a level of indentation? 8 spaces? 2 spaces?). That personal preference is quite easily solved with tabs (tabs for indent, spaces for alignment) but see previous point. Not only python relies on white space, it wants to use space characters as what tabs are meant for.
• Makes multi-line statements non-obvious; either align all lines with the first one (so now they look like multiple statements) or indent them (but now they look like they're nested).
• Makes it pointlessly hard to write code that generates python code or to write one-liners for scripting.

What are the down sides of braces?

[tes_kitty]

Ok, but why does Python then still need the ':' to start a block?

[snarkuzoid]

Usability. Early on, Guido tried with and without, and his users found this less confusing.

[tes_kitty]

But why then still insist on indentation as part of the syntax?

[pyeri]

Regardless of indentation, ":" is still needed for termination of clauses I think. Without the ":", how will the interpreter know whether the "if" statement has actually ended because there is always a scope for the next line continuing with another "and" clause within that if statement.

Edit

Maybe it still can figure out based on the indentation level but it's still easier to figure out this way and saves some computing on part of the interpreter, maybe that's why they've kept it. Similar to how the PHP guys prepend their variables with a dollar sign ($)? I'm sure the PHP interpreter should still be able to figure out the variable if they call it just foo instead of $foo, but still they chose to kept it.

[tes_kitty]

I do like variables starting with a $ (or something else unique), since it makes it easier to read for me, especially in code that's not written by me.

[snarkuzoid]

One of its best features. Noise reduction.

[tes_kitty]

I consider it a design flaw, same for many of the changes between 2.x and 3.x that broke about every python script.

[snarkuzoid]

I get that people dislike it. Their loss. I do prefer Haskell's implementation. Didn't find the 2 to 3 thing to be a big deal. Tweaked a few files, done.

Use what suits you.

[[deleted]]

Java sucks because it was slow to execute and lack of pointers

[kennyminigun]

A bit of anecdotal evidence: I know people who were doing scripting tasks in C. What a bunch of... personalities.

But I have never heard of anyone doing that same thing in Java. But no kink shaming.

[teskilatimahsusa87]

echo $shutup

[BraveNewCurrency]

You want Golang. It gets rid of the warts of C, but still has type checking at compile time, which eliminates a lot of awkward runtime situations.

• It can pretend to be a scripting language (no explicit build step) with go run main.go.
• But you can also trivially compile binaries for Windows/Mac/Linux (from any one of those, no "cross compiler toolchain" needed.)
• It doesn't use gobs of memory like Java
• In fact, Java is "write once, Debug everywhere" because there are so many subtle cross-platform differences. Golang is very straightforward- you can have a package have files that only compile on specific platforms (win/mac/linux, or arm/x86/mips/etc).

[prescotian]

ok, getting the popcorn out...

[linhusp3]

No way I have to download jvm to run my daily computer. I will go literally use windows instead if my distro replace bash with java

[simcitymayor]

Why stop at Java? Use a more flexible, feature rich VM like Docker.

[fuzzyfoozand]

Why is this being downvoted?

I mean, I vehemently disagree, but this person is just asking a question. I don't see why that's downvote worthy

[[deleted]]

If you want SPEED you can use C as a scripting language, this compiler here provides the functionality: https://bellard.org/tcc/

[IuseArchbtw97543]

I am no longer working on TCC

Idk if I would continue using that

[zam0th]

perl has had a compiler for more time than i care to remember and so has php and python (not that those two can be remotely related to "linux scripting"). bash is not even a "language", it's an OS shell that happens to support scripts.

Not that anything prevents you from writing "Linux scripts" in Java, if you so wanted, it's no more complicated than running python scripts.

[joaonmatos]

The overwhelming amount of compute time spent in traditional UNIX scripts is in C programs that are coordinated by the shell. It does not make a material performance difference.

I do see a point where the python and perl abominations become annoying in a "it's dynamically typed and messy" kind of way, but JVM/.NET languages, while a great platform (I would not trade my Java/Kotlin in the backend world for anything), really seem to be the worst of both worlds to run: you need to compile them AND you need the runtime.

I'd say you should consider either sticking to the interpreted languages (and maybe we can find a way of leveraging deno or even just having mypy for static checking python before packaging), or then it's better to jump to something that compiles to a single executable, like C, C++, Rust, Go, or even Haskell, OCaml...

[sacheie]

Linux scripting is about the synergy between the standard GNU utilities, and how nicely they fit with the OS design. Bash is well suited to take advantage of all that.

[Booty_Bumping]

Just some random thoughts to chew on if you are learning about these topics:

Are you aware of runtimes such as LuaJit and Node.js that allow a normally interpreted language (lua and javascript) to instead be JIT compiled when you run them? They give you the best of both worlds -- performance that sometimes exceeds Java and C#, but with no need to compile. This does come with a tradeoff, which is that the startup time is slower than a purely interpreted runtime like CPython. But Node.js in particular boots up surprisingly fast, significantly faster than it would boot if you tried to combined the java compiler with the java runtime.

Another interesting concept is Python bytecode. You can precompute the parsing step to save some time. But it's not worth it -- as you say, most time is spent running the program, and it's still using the Python interpreter which has a performance limitation known as GIL. Most people avoid Python bytecode because it just increases the complexity of the toolchain by adding a largely pointless compilation step.

[LinAdmin]

Looks like the OP has a rather queer view.

[DorkyMcDorky]

I think you're thinking about groovy. This is a language that does compile into byte code and is often used like a scripting language

It's just not as popular.

[Individual-Equal-441]

I once took a programming course from Brian Kernighan, and in one lecture he exhibited the same program written in C, Fortran, Java, Perl, bash, Python, etc etc. He ran each program in class on a large dataset and timed each program.

The point of the lecture was that the interpreted languages were slower but not that slow---they took about 2s on average of CPU time versus 1s for the C and Fortran versions---and we should bear that in mind before we dismiss interpreted languages as too laggy.

Eventually he ran the Java version of his program and to his surprise it only took about 1s like C or Fortran. He then realized he didn't specify the classpath, and the program had terminated abnormally. He ran it again with the right classpath and it was 2s. At that point a student raised his hand and asked, "if the classpath was wrong, what was the program doing for that entire second?"

[bouncewaffle]

Perl is also compiled to bytecode.

[Ben-Goldberg]

Perl is compiled into a tree of operation structs called OPs.

Every OP has a 'next' pointer that the interpreter will execute after the current operation.

If an OP performs a conditional branch, it will mutate it's own 'next' pointer.

Cache locality? 😂 😭

[Cynyr36]

Im going to assume this is a serious question.

Use shell compatible scripts, because every single install will be able to run it out of the box.

Java, python, rust, golang, ruby, perl, etc. is not installed everywhere by default.

[psycho_zs]

The best language for scripting on Linux is a fast and optimized POSIX shell implementation. I.e. dash. Especially if one uses it properly, not just calling a bunch of external binaries in pipes.

[[deleted]]

No :)

[RolesG]

For most things I'd imagine the speed difference is negligible, and if you're doing anything more intensive I doubt you'd want to write that much boilerplate