They’ve aggressively stated they’re a cis woman and has found the implication of her being trans incredibly insulting.

Yeah I completely agree with you, but sometimes there are other things that jankier languages allow you to do. Say in python, you can do direct property assignment. This is gonna be annoying for someone later to figure out why their object has suddely changed, and without getters and setters, you’ll have a harder time picking apart what’s going on. The benefit though is that it’s very quick to just tack on a property onto some global object and then have that read elsewhere down the road.

It sucks, and you will curse yourself later, like you don’t even know what type it is, or maybe it’s just null, however it did allow you to ship a project. Maybe that bodge solution is indicative of needing a complete overhaul on how you structure your project, but until you get to that point where you’ve scoped out what the final idea looks like, it might not be time for static typing and good code design.

I also think that static typing and such makes you move a lot slower when making changes. I love rust to bits, but maintaining an old project is like wading through treacle. I only jump towards using it now once I’ve got a really great understanding of all the needs of the system, and have the time to really think about the problem in its entirety. Maybe you suddenly need a mutable self in somewhere that you didn’t before, perhaps that means going and refactoring a whole load of traits that were designed without mutability (for good reason).

Hey its better than nothing? Haha

If performance isn’t an issue, I’d take it over nothing for long term support

Time to delivery is important. Moving quickly withing a language and frameworks that prioritise speed over safety gets a product out the door is important when testing whether a business idea holds merit. Once you’re established with a better scope of the project you should be rewriting this in a static language.

Dynamically typed interpreted languages should never be used for long term support imo

It feels like maybe this could be a code structure issue, but within your example what about something like this?

fn main(){
    let mut counter = 0;
    let output_array = array.into_iter()
        .map(|single_item| {
            // breaks the map if the array when trying to access an item past 5
            if single_item > 5 {
                break;
            }
        })
        .collect()
        .map(|single_item| {
            // increment a variable outside of this scope that's mutable that can be changed by the previous run
            counter += 1;
            single_item.function(counter);
        })
        .collect();
}

Does that kinda syntax work for your workflow? Maybe it’ll require you to either pollute a single map (or similar) with a bunch of checks that you can use to trigger a break though.

Most of the time I’ve been able to find ways to re-write them in this syntax, but I also think that rusts borrowing system although fantastic for confidence in your code makes refactoring an absolute nightmare so often it’s too much of a hassle to rewrite my code with a better syntax.

Oh sorry, I misread what you typed and went on a tangent and just idly typed that in.

One thing you could do for your situation if you’re planning on iterating over some array or vector of items is to use the inbuilt iterators and the chaining syntax. It could look like this

let output_array = array.into_iter()
    .map(|single_item| {
        // match here if you want to handle exceptions
    })
    .collect();

The collect also only collects results that are Ok(()) leaving you to match errors specifically within the map.

This chaining syntax also allows you to write code that transverses downwards as you perform each operation, rather than transversing to the right via indentation.

It’s not perfect and sometimes it’s felt a bit confusing to know exactly what’s happening at each stage, particularly if you’re trying to debug with something mid way through a chain, but it’s prettier than having say 10 levels of nesting due to iterators, matching results, matching options, ect.

Just use this syntax

let myResultObject = getResult() 
let item = match myResultObject {
	Ok(item) => item, 
	Err(error) => {
		return;
	} 
};

Yup, never nest.

All the conditions should be checked and returned if they failed as you go through the function with the successful response being the last line.

The game is absolutley worse with analogue controls.

I’m on a 2060 super with Manjaro and I haven’t had any issue with drivers other than when I accidently uninstalled all the drivers at once, and then it was just a matter of running a command found from googling to get it back up and running.

I haven’t tried an AMD card, and I’m strongly considering it for my next, but I just haven’t seen you have a issues people report.

There is valid performance based reasons to use an app over a browser based experience. Sure perhaps it’s just data collection, but being able to cache locally and have that information persistent between uses dramatically drops the initial page load time.

But yeah, it’s annoying as hell to be bothered about it, and usually compromising the performance/load time is worth not having to go through the hassle of downloading an app.

Edit: Seems like I was wrong. I remember reading about how in general native apps would make significantly fewer API calls than identical website based experiences, even with the user having navigated to the site before.

Yup, super quick to throw a cut together or some basic footage. It won’t replace the full adobe suite, but if you want to cut basic videos together it’s perfect