[veidr]

Wild take, but agree with your first sentence.

1.) it was never a language

2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.

[LunaSea]

I see close to no case where you would not enable all access rights

[veidr]

Well they might not be your use cases, but surely you can imagine them, right?

A build tool, that reads input files and writes output files, and nothing else.

A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

A serverless function that doesn't need anything but networking.

Even when you need to allow whatever you're building to read the filesystem, just specifying which files/folders can be read is in an of itself a huge win.

Thinking on it a little more, I wonder what kind of gigantic monolith use cases are there that need to read/write completely arbitrary filesystem locations, and need to spawn subprocesses that can't be known ahead of time, and need to do networking, and need to read arbitrary environment variables that can't be specified ahead of time, and also need to load dynamic libraries, and also need that other permission I'm forgetting?

I mean, I am sure there are some, but that certainly isn't the default I'd choose.

[LunaSea]

> A build tool, that reads input files and writes output files, and nothing else.

If it wants to upload artefacts to a CDN it will also require network access.

> A CLI that interacts with the bug tracker, and needs to read the environment variables and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

Chances are the CLI needs to read ENV variables to authenticate or a configuration file and maybe even subprocesses to setup parallel processing.

> A serverless function that doesn't need anything but networking.

A serverless function will probably read environment variables as well or access a package.json file to read some context about the name of the package and it's version.

My point is that most programs will require all access enabled.

[veidr]

I know that's your point, but I don't understand why you think that.

Even with your own theoretical additions to what the programs above need, none of the programs above actually need "all" access enabled.

And even when you do need to allow environment variables, subprocesses, and filesystem access, you can specify which ones. E.g. this program can read this specific package.json file and no other files. Or these three specific environment variables, and no others.

Which is still significantly different than "all".