Uh I'm confused, so you think my take is bad because memory safety should not matter ?

I think its a bad take because "Developers are not Idiots" and "be disciplined" are not good arguments. Its just choosing to ignore the problem rust solves.

I am fine with ignoring the problems that rust solves, but not because I'm smart and disciplined. It just fits my use-case of making fast _non-critical_ software. I don't think we should rewrite security and networking stacks in it.

Then we're sort of in agreement.

I don't think you need the ritual and complexity that rust brings for small and simple scripts and CLI utilities...

And rust doesn't market itself as small and simple scripting language?

Choose the tool that fits your usecase. You would never bring wasm unity to render a static html file. But if you make a browsergame, you might want to.

    The thing I wish we would remember, as developers, is that not all programs need to be so "safe".

"Safety" is just a shorthand for "my program means what I say". Unsafety is semantic gibberish.

There's lots of reasons to write artistically gibberish code, just as there is with natural language (e.g. Lewis Carroll). Most programs aren't going for code as art though. They're trying to accomplish something definite through a computer and gibberish is directly counterproductive. If you don't mean what you write or care what you get, software seems like the wrong way to accomplish your goals. I'd still question whether you want software even in a probabilistic argument along these lines.

Even for those cases where gibberish is meaningful at a higher level (like IOCCC and poetry), it should be intentional and very carefully crafted. You can use escape hatches to accomplish this in Rust, though I make no comment on the artistic merits of doing so.

The argument you're making is that uncontrolled, unintentional gibberish is a positive attribute. I find that a difficult argument to accept. If we could wave a magic wand and make all code safe with no downsides, who among us wouldn't?

It doesn't change anything about Super Mario World speedruns because you can accomplish the same thing as arbitrary code execution inputs with binary patching. We just have this semi-irrational belief that one is cheating and one is not.

> If we could wave a magic wand and make all code safe with no downsides, who among us wouldn't?

Anybody would, but Rust is not that wand, and there is no wand.

Code needs to _exist_ in order to matter. Time is finite, my free-time is even more limited. Most of my code is garbage collected, and runs great, but if I needed it to be really fast, I would use Zig.

I don't need to be told what software is for or how to accomplish my goals, and I'm sure you wouldn't understand my goals. I've been making code creatively for almost 30 years. You might as well tell an origami artist that folding paper is a bad way to accomplish their goals.

The attitude among _some_ Rust devs (or armchair coders) that there is no place for non-rust manual-memory languages is insanely disconnected with reality. Games exist, Rust ones hardly do. Synths exist, Rust ones hardly do. Not everything is a high-availability microservice or an OS kernel! Look around!

Edited to add:

> "Safety" is just a shorthand for "my program means what I say". Unsafety is semantic gibberish.

You know this isn't true, right? "Safety" in Rust specifically means memory safety and thread safety: no use-after-free, no data races, no null/dangling pointer dereferences, no buffer overflows. That's it. It doesn't guarantee your program is correct, and it doesn't even prevent memory leaks.

Things being manually managed doesn't make them gibberish, and something being implicit, rather than explicit, doesn't mean its gibberish.

The attitude of Rust being bug-free is _insaaaane_. A "bug" is just code that breaks expectations, I promise we can and will write those in every language forever.

I want to be clear here because I think you might have read that as less precisely worded than I intended.

When I say "my program means what I say", that means the code that is written has some precise meaning that can be faithfully translated into execution (sans hardware/runtime/toolchain bugs).

This is different than "I said what I mean". If you write different code, that may violate expectations and create a bug, but it will still be faithfully translated as written.

Safe Rust attempts to guarantee this with the absence of UB. The definition rust uses still isn't a universal definition, which we agree on. That's why my comment didn't actually talk about Rust. The definition I used should be valid no matter what particular guarantees you choose.

    Things being manually managed doesn't make them gibberish, and something being implicit, rather than explicit, doesn't mean its gibberish.

I completely agree. I like C, for what it's worth.

Where we disagree is that I'm saying this doesn't scale. A large enough program (for a surprisingly small definition of large) will always have gaps and mistakes that violate your chosen definition of safety, and those bits are the gibberish I'm talking about.

I understood and considered both things you could have meant. Either way I think you come off as an armchair coder that overstates what rust safety actually is (its not abstract, i enumerated it). You are doing rust a disservice in the most stereotypical way. I have no more time for this, going to go play one of hundred of thousands of gibberish games.

> The attitude of Rust being bug-free is _insaaaane_.

Funny, because that's not anywhere close to what the comment you're replying to states.

They said `"Safety" is just a shorthand for "my program means what I say"`. That's a reasonable explanation: the code you wrote is not working exactly as you intended, due to some sort of unknown behavior.

The "bug" you're talking about would be the program doing exactly what you implemented, but what you implemented is wrong. The difference is so obvious that it's hard to think that you're engaging in a good faith argument.

You are not doing Rust any favours by arguing that code that may have memory safety issues is gibberish and something that could be associated with the IOCCC. Ramping something up to 11 makes it hard to take seriously.

You could write rust code with logic errors. I could write C with a memory leak that doesn't matter because of the context it runs in. Neither program is gibberish but one of them causes real problems.

I'm not making either of those arguments. I'm not even using IOCCC as a pejorative association. The comment you're responding to explicitly compares IOCCC code to poetry and Lewis Carroll. One thing I am saying is that most code isn't written for those kinds of purposes. I can't imagine that's a controversial statement though.

I'm open to suggestions on how to clarify things as you're the second comment to misunderstand it and I'm not sure how to better explain it.

If you want or need the guarantees Rust provides, then go ahead and use Rust. If you want to handle the guarantees yourself, then Rust may not be the language for you. You can still have bugs whether or not you use Rust, so your Rust program may have some form of unsafety. In Linux, a Rust program with setuid root can lead to privilege escalation vulnerabilities, even if it doesn't contain a single line of "unsafe" code.

Either way, telling someone they have to pick between using a safe language like Rust and writing "semantically gibberish" is a false dichotomy. Please don't call programs written in memory-unsafe languages semantic gibberish until you prove that there are absolutely zero bugs in your program.

I think you have both misread the comment you replied to and misunderstood the concept of memory safety.