I tried something like that once. Basically, I was trying to create an API with which sysadmins could script deployments. That involves lots of strings, so I was hoping I could avoid the String vs. &str split by making everything &'static str.

And yeah, the problem is that this only really works within one function. If you need to pass a parameter into a function, that function either accepts a &'static reference which makes it impossible to call this function with an owned type or non-static reference, or you make it accept any reference, but then everything below that function has normal borrowing semantics again.

I guess, with the former you could Box::leak() to pass an owned type or non-static reference, with the downside of all your APIs being weird.
Or maybe your prototyping just happens at the top and you’re fine with making individual functions accept non-static references. I guess, you’ll still have to try it.

Since you’re already at the bargaining stage of grief programming, maybe you’re aware, but Rc and Arc are the closest you can get to a GC-like feel. These do reference counting, so unlike GC, they can’t easily deal with cyclic references, but aside from that, same thing.
Unfortunately, they do still have the same problem with passing them as parameters…

I also never had an accident where I needed the seatbelt

I really wanna know where you get your language info and examples from because nearly every single one you wrote in your comments is just wrong.

Program state in Rust isn’t immutable. datastruct.nextState() is not only possible, but perfectly reasonable, it’s exactly how iterators are implemented.

How many bugs you encounter is unfortunately not a good metric, because devs will compensate by just thinking harder. The goal is rather to not need to think as hard, which increases productivity and helps out your team members (including your future self).

It took me a few months of working in an immutable-by-default language before I had the epiphany that everything is exactly like it’s written down in code (so long as it’s not marked as mutable). I don’t need to look at each variable and think about whether it might get changed somewhere down the line. A whole section of my brain just switched off that day.

As the other person said, there’s also nothing stopping you from using mutability, it’s just not the default, because most variables simply don’t get mutated, even in C code.
But I would even go so far that Rust is actually making mutability fashionable again. It has introduced various new concepts in this regard, which you won’t know from other languages.

For example, you can opt a variable into mutability, make your changes and then opt out of it again.
And if a function wants to modify one of its parameters, you have to explicitly pass a mutable reference, which is visible both in the function signature and where you’re calling the function.

But perhaps most importantly, it blocks you from mutating variables that you’ve passed into a different thread (unless you wrap the value in a mutex or similar).
In most of the immutable languages up until this point, the immutability was achieved by always copying memory when you want to change it, which is insanely inefficient. Rust doesn’t need this, by instead requiring that you follow its ownership/borrowing rules.

Edit:
I also don’t know what you heard, but this is for example written in Rust: https://bevyengine.org/examples/3d-rendering/bloom-3d/
The code is right below. It uses lots of mutability…

You can just. Have datastruct be mutable if you want. Immutable by default doesn’t mean you can’t make variables mutable.

No thanks, I’ll be staying with datastruct.nextState() rather than const nextState = prevState.nextState()

You can easily do the first option in Rust, you just use the mut keyword. That’s it, nothing more than that. And you’ll find that you quite rarely have to do that, and when you do it, it’s actually quite a useful signal to be aware of, since mutability sometimes means a bit more surprising data changes.

You don’t need to do any of those things with Go or Rust. Interfaces/traits provide the capability for dynamic dispatch.

Well said.

Here I am trying to wind people up and you’re responding with thoughtful nuanced consideration.

You make some great points.

I’ll add - for folks reading along - I do think a class is still almost always an anti-pattern, even with all the OOP class function and factory pattern stuff removed.

I also feel (as you referenced):

• Functions being forced to reside inside objects is just stupid.
• Factory patterns are horrible, because they mix config into program code, maximizing uncertainty when debugging

And also:

• Inheritance is almost always a worse idea than an interface.
• classes tend to have additional fancy tooling to make it easier to carry state data around - which is usually a bad idea

State data is a necessary evil in most programs.

I’ve found that most advanced class object implementations treat program state data more like a pet than a threat.

Sorry for the long response - I know you don’t need it - you know what kind of tool you’re looking for.

I figure they extra detail above might provide food for thought for folks reading along who are surprised there’s even contrasting opinions on classes.

(And I feel a little bad for not really posting anything very useful earlier in the thread.)

The problem with classes is inheritance. Inheritance is just a bad idea and a bad way to structure stuff if you ask me.

Rust fixes this neatly with traits that basically provide the same benefits as classes without any of the downsides.