That doesn’t help you if you want to get the result of something that happened in the function without capturing stdout, does it?

I didn’t mean that bash has no local variables, but rather that if you want to use a function as such without capturing stdout, you need variables that are scoped across your functions, which is usually global or at least effectively global.

Bash has its upsides too, like the fact that it has arrays / lists and dictionaries / hashmaps. In my opinion, it gets iffy though when you need to do stuff with IFS; at that point one might be better off just using specialized tools.

Not saying working bash isn’t good enough, but it can break in very surprising ways is my experience.

Functions are definitely not subshells in Bash

You’re right, my bad, I got this mixed up with something else.

Not sure I’d call what bash has functions. They’re closer to subroutines in Basic than functions in other languages, as in you can’t return a value from them (they can only return their exit code, and you can capture their stdout and stderr). But even then, they are full subshells. It’s one of the reasons I don’t really like Bash, you’re forced into globally or at least broadly-scoped variables. Oh, and I have no clue right now how to find where in your pipe you got a non-null exit code.

It’s not a big problem for simple scripting, but it makes things cumbersome once you try to do more.

In all seriousness though, the core of the technical stack has become very robust in my opinion (DNS being the exception). From a hobbyist’s perspective, things work much better than when the Web was still young. I can run multiple sites (some of them being what are today called apps) on a domain with subdomains, everything fast, HTTP3-capable, secured via valid free TLS certs, reverse proxied, all of that running on a system deployed in minutes…

If you focus on the part of the Internet that you have control over, it’s a lot better than back in the simple days.

Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.

I don’t think the broader zig community has the rewrite spirit that the rust community has. For Rust, this mentality was also motivated by an increased security, which zig does improve over plain C, but not to the extent Rust does.

To preface anything that follows, I’m not a developer, so this is little-informed opinion.

Writing in rust just doesn’t seem very enjoyable. It’s a language with security in mind, which is a good thing. However, zig also isn’t inherently insecure (though it doesn’t provide the same security guarantees) and coding in it just seems so much more pleasant. To me, the language makes more sense, which is also something I like about Go. Even manual memory allocation looks well-designed. At no point did I look at zig and thought “oh, that’s an odd choice”.

The language isn’t frozen yet though, so everything you write in it may require changes later on, so I wouldn’t recommend it for anything in production. Notably, there’s no built-in async or something comparable. If you’re fine with these limitations, go ahead and try it out, and if you feel like it, maybe even rewrite an existing tool in it.

ncdu for example is such a tool where the original author rewrote it in zig for version 2.