you have 6 problems

you introduce rust, now you have 30 problems

you worked on it for about a month and maybe this is the 6th rewrite, and you now have 300 problems and also you have less functionality than every one of the previous versions

why and how

this pattern seems to be consistent no less

Maybe the issues that Rust brings are worse than the issues it resolves. I mean, C++ resolves already a lot of memory issues. Migrate :D

@retoor I fucking love C++. I am a masochist

@retoor C++ is scary. C is nice, C tells you everything, it's transparent. C++ you have no clue on what the fuck is going on. It's somehow simultaniously low level as fuck and high level as fuck, like some ungodly mix of the C and Java/C# but in a cursed way.
(P.S. I love both C and C++. C more tho)

I haven't worked much with Rust.

Oh wait , this is your profile.

good morning.

fuck you :)

@retoor Not really. C++ is less restrictive than Rust, but all the things Rust doesn't let you do are also things you *shouldn't* do in C++

The real issue is that robust programming without a GC is just hard. There are no easy solutions.... well except a GC. But you can't always have one

@12bitfloat where comes that big hate for the gc comes from. No need I guess. What applications are we writing ffs? Retoor script doesn't work with tuttyfrutty, that's why it's amazing. Tuttyfrutty is bad and C++ and Rust have it. Doesn't matter that you never had issues with tuttyfrutty. It's bad. It's old. Nobody can write safe tuttyfrutty.

@SoldierOfCode I've the feeling we've met before. Sure, but you still can use valgrind right? Also, maybe it's a good idea to use only a smol subset of what C++ has to offer. I think many people are doing that. Not doing Rust? You have the age for it, you're only missing cat ears. I'm sure they'll look great on you.

@12bitfloat could you explain how GC helps at all for robustness? Any sane data structure does not require garbage collection.

@retoor No no, I love GCs

@iiii GCs automatically prevent use after frees and double frees, so they can definitely help writing more robust software. But nulls are still a problem in many GCed langs

@12bitfloat they don't really. Otherwise Java would not be so notoriously famous for NullPointerException despite being a garbage collected system. It very much depends on the implementation of the collector.

@iiii Nulls aren't a problem of automatic memory management. Newer languages like Kotlin also have null-safety

But for real, you can't tell me manual memory management is somehow more robust than a GC. That's absurd

@12bitfloat it's robust if you don't do stupid things. And does not waste memory because of no GC

@iiii "if you don't do stupid things" is kinda the point though. Because when a simple programming error can cause big problems, that's not a robust language

Btw I'm not hating on either. Sometimes you really do want manual memory management. But god damn do I like GCs

Wasted memory is true though. But I don't understand why that happens

Man, now I want to write a GC just for fun lol

@12bitfloat on of my languages had the gc very smoothly implemented and came almost for free due good design and with one I just couldn't figure it out. I divided once to do the garbage collection later, big mistake.

@12bitfloat it's not really "a single programming error" that does bad. it's a deliberate ignoring of proper ways of doing things. can't really do that by accident

@iiii Bruh. That's definitely not how any of this works. "Just don't make mistakes bro"

Google, Microsoft and others have ~70% of their bugs due to memory unsafety. If you think it's so easy then you're enormously naive

@12bitfloat where does that statistics come from?

@iiii Offical posts ( it was CVE's not bugs in general, oops):

https://msrc.microsoft.com/blog/...

https://security.googleblog.com/202...

@12bitfloat those don't talk about bugs, but about vulnerabilities. it's not the same thing

@iiii I know right, who cares about these boring vulnerabilities

@12bitfloat no, it is important. It just does not constitute the whole set of bugs overall. Most bugs are logical bugs, not memory management. Most vulnerabilities are memory management related things. But errors in memory management are also arguably logical bugs (lack of boundary or size checks and such)

@jestdotty not every bug is a vulnerability.

@iiii Sure but what's the point? You have logic bugs either way, at least you don't also have to worry about memory safety bugs (which are way more dangerous). Seems pretty clear what's better

@12bitfloat the point is I've started from stating that most bugs are logical errors, not memory management errors. You've stated some statistic which actually is about vulnerabilities, and not bugs overall, so it's not something directly related to the first statement.

@12bitfloat and yes, having to bother less about memory handling errors is good but it can be done with proper code style and static analysis, and does not require rust. Rust is basically a compiler with static analysis baked in.

@iiii No it can't be, you're just flat out incorrect. It can be improved via static analysis but it will never be "fixed"

You think google and microsoft are stupid? You think they aren't already using a lot of these tools?

C++'s ideas like RAII were great. In fact new low level language depend on similar ideas. But you can't have all the old ways (with much more intuitive syntax) and expect that nobody ever accidentally or ignorantly uses them

That maybe works for your own projects (and even that I doubt -- I bet I could find UB), but it doesn't work at any sort of company scale

@12bitfloat Google and Microsoft have another issue: a huge working codebase. Which cannot be easily rewritten or re-architectured

@iiii Oh definitely, that's why "rewrite everything in X" is stupid. But for new projects it certainly makes sense to pick a more robust language

@12bitfloat fair enough

Maybe we should hire someone to sniper rust team