I literally like bash more than rust for command line tools

it's more readable

was trying to pick up a good semi-complex project to wrangle with my ownership management style

it kept suggesting things I wouldn't use

but there was a git tool / some git utilities I wanted... I deleted the notes from my note app by now so I have to go by memory but whatever

thing is... one of the scripts I already have in bash. it's so damned short in bash. it would be so ridiculous in rust. not to mention the more complex scripts that were supposed to be my little self-induced masochism experiment

um yeah I think bash scripts are both easier to propagate to new systems / when I reinstall my operating system, easier to run, read, debug... and to reason about because you can fit them on one screen

wtf are we doing

@jestdotty why would you use rust for command line?

Also, brevity doesn’t mean readability.
JS minification is the proof.

Unless you are some kind of freak who thinks that one letter names are readable lol.

@Lensflare brevity means readability to me because I have memory issues

it has less to do with one line variable names and more with extra brackets and newlines. ofc you can write one line variable names in anything so it can't be that that I'm talking of

rust is used for commandline often which is why it's used for command line often

@jestdotty Obviously just calling other cli tools in a bash script is easier and shorter than writing it yourself in a programming language. That's why the command line rules!

But also: There are areas were Rust can be annoying but CLI tools are absolutely perfect for Rust

Input -> Processing -> Output, all very nicely tree-like starting from the stack. No global variables, long running subprocesses, async, etc.

That's the one thing where Rusts ownership model works *very* well. If ya can't make *that* work in Rust that's really just on you

@jestdotty

> rust is used for commandline often which is why it's used for command line often

That’s some flawless reasoning 😂

@12bitfloat yeah I can do that

I'm trying when you need rc refcell or other strategy and not making it a mess

maybe I'm thinking too big when rust is for tiny tools or somerhing

@Lensflare r u trying to steal my joke

@jestdotty that was a joke? Not even I would try to steal that. And that’s coming from a German!

@jestdotty Rust is a serious tool for serious programs

Rc<RefCell<>> doesn't work. Don't use it. Its a crutch if you don't know how Rust works

Think about the ownership and how it naturally flows via borrows. Think in a tree-like way where the seed is in the main function on the stack and you delegate things down the call stack instead of having a bunch of autonomous global objects which do their own thing

It's not always easy (the downside of memory safety in a systems lang) but it does work very well

But you have to divorce yourself from the typical Java-like grug programming style. You can't program Rust like a junior level webshit who only produces spaghetti

Its a serious tool which has to be wielded with serious thought how to use it

The only use case on which Rust and shell scripts overlap is build automation. I love my xtask binary because it's exactly as portable as the project itself; every target is a dev target. But the same applies for any other language; your language has to have supremely shitty abstraction capabilities for it to be a bad idea to use it for build automation.

The other side of this coin is that my barrier for something that's too complex to be serviced by a shell script is quite low. If you need xargs, you're probably past it. If you (semantically) need a conditional inside xargs, you're _definitely_ past it. If you need to edit it often, if more than one person needs to edit it, if it stores anything more than plain-value tables (either nested structure or references across tables), if it might be used by people who can't read it, or otherwise requires error handling besides basic argument validation.

@12bitfloat screeps easily devolves into ownership problems

yes tree. what if nodes of the tree have to talk to each other? now what?

@jestdotty MPSC queues are a big help.

@jestdotty slotmaps! Instead of each nodes doing the logic on their own, have a function which evaluates the logic *for* a node. That function gets passed &mut Context, which contains all the slotmaps for different entities. When you need one you query it from the context object

Don't overcomplicate things and be smart and lazy. 😂

@jestdotty Global vars bad, local vars that you borrow to functions good

At least when doing Rust

@12bitfloat root of tree would be a slotmap

wait multiple slot maps...

but the context is global

@jestdotty Okay how do you not understand this 😭

You pass things up the call stack

No global variables

If you want your function to have the data of your program you pass it via a reference

@12bitfloat think this will introduce problems rather than solve them in my context

had AI choke up a graph example

but for mine then I'd be having slotmaps left and right and it isn't like I can't make unique IDs. I actually have tons of them. sometimes quite nested ones

when I said tree structure I thought we were talking of a metaphorical tree-like sprawl over the whole codebase, of how to organize structs sprawling out into more structs and etc. not just a graph data type

like empire owns rooms which owns services

creeps need to access services and to do that they need to know which room and the service id to be able to go back down the chain to access that struct, which then means it's effectively/metaphorically a 2 key index

Bash is great.

@Lensflare while JS minification is the extreme and fully agree with the brevity statement I do think single letter variable names are good. The distance of usage is very important here. I'll take single letter "i" over a java style "SkibidyToiletBrushIterationIndex" every time for a close loop. Now on the API that is more distant from the code I want more context.