Go away Python

> Sidetrack: I actually looked up what the point of arg0 even is since I failed to find any usecases some months back and found this answer[0]. Confused, and unsatisfied by the replies, I gave up trying to understand "why arg0?" as some sort of legacy functionality.

I struggle to think of how the answers provided here could be clearer or more satisfactory. Why write an article if you're going to half-ass your research? Why even mention this nothingburger sidetrack at all...? (Bait?)

[0] https://stackoverflow.com/questions/24678056/linux-exec-func...

Go is poor for cheap scripts for one reason: error handling.

It’s great for “robust” code, not for quick things that you’re okay with exploding in the default way.

came here to say the main trick has also been possible for C and Java. The C version has already been pointed out in sibling comments, while Java one requires more "tricks" in terms of bash substitution.

I remember I built a such java "interpreter" during my first year of university (10+ years ago! time flies fast...) because the initial intro/101 courses always had one-off programs and the main language was java.

although I no longer have the original source(s) it was something like

///usr/bin/env javac $0 && java ${0%%.java}; exit; # /

since it's quite simple, I even had a funny named wrapper called "java-script" (pun intended) in my $PATH so that I could just write

//usr/bin/env java-script # /

at the top. As you can see I already confused fellow students with the great naming scheme I used :)

Tangent but... I kinda like the Python language. What I don't like about Python is the way environments are managed.

This is something I generally believe, but I think it's particularly important for things like languages and runtimes: the idea of installing things "on" the OS or the system needs to die.

Per-workspace or per-package environment the way Go, Rust, etc. does it is correct. Installing packages globally is wrong.

There should not be such a thing as "globally." Ideally the global OS should be immutable or nearly so, with the only exception being maybe hardware driver stuff.

(Yes I know there's stuff like conda, but that's yet another thing to fix a fundamentally broken paradigm.)

really good post thanks lorentz :D

> I started this post out mostly trolling

So your goal was to waste your reader's time. Thanks.

argv0 is very necessary for use cases like busybox

What about Mojo?

skill issue

Yes, you can but should you?

>This second method is, by the way, argued to increase compatibility as we utilize env to locate bash, which may not be located at /bin/bash. How true this is, is a topic I dare not enter.

At least it seems important on NixOS, I had to rewrite a few shebangs on some scripts that used /bin/bash and didn't work on NixOS.

I remember when I first experienced golang, I tried compiling it.

The compilation command returned immediately, and I thought it had failed. So I tried again and same result. WTF? I thought to myself. Till I did an `ls` and saw an `a.out` sitting in the directory. I was blown away by how fast the golang compiler was.

Now try to call some C++ code from your Go script…

> I started this post out mostly trolling, but the more I've thought about it's not a terrible idea.

I feel like this is the unofficial Go motto, and it almost always ends up being a terrible idea.

[dead]

[dead]

[flagged]

Using `uv` with python is significantly safer and better. At least you get null safety. Sure, you can't run at the speed of light, but at least you can have some decent non-halfarsed-retrofitted type checking in your script.

    Try the following in sh:

    ////////usr/local/go/bin/go 

Somehow I have been doing so since +25 years. Never regretted it. Never really needed shell either. (Ok, that's not entirely true; I refer to shell scripts. I do use bash as my primary shell, largely due to simplicity; I don't use shell scripts though, save for keeping a few legacy ones should I be at a computer that has no support for ruby, python or perl. But this is super-rare nowadays.)

So the entire reason why this is not a "real" shebang and instead takes the roundtrip through the shell is because the Go runtime would trip over the # character?

I think this points to some shortcomings of the shebang mechanism itself: That it expects the shebang line to be present and adhering a specific structure - but then passes the entire file with the line to the interpreter where the interpreter has to process (and hopefully ignore) the line again.

I know that situations where one piece of text is parsed by multiple different systems are intellectually interesting and give lots of opportunities for cleverness - but I think the straightforward solution would be to avoid such situations.

So maybe the linux devs should consider adding a new form for the shebang where the first line is just stripped before passing the file contents to the interpreter.