6 ms·
Rust is a frustrating language for me too. I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically imposs
by nwallin 3y ago
Rust is a frustrating language for me too.
I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically impossible for memory leaks/use after free/use outside of bounds to occur or if they do occur, explode loudly in debug environments. I haven't used new/delete in a personal project in like a decade; longer than Rust has been around.
Now I'm working on a project where the main developer is...a cowboy. Everything is insane. Not only is new/delete everywhere, but so is malloc/free. In C++ code. You have to navigate to where the thing is allocated to figure out whether to use free or delete. Everything leaks, everything crashes, everything races, everything deadlocks.
Oh and the guy is my boss.
So on the one hand, rust might fix these problems, on the other hand, rust is a non-starter.
So now what. I still don't need rust because I don't code like a crazy person. And the people who do code like crazy people will never use it anyway because it doesn't let them...express themselves.
- nindalf 3y agoHell is other people’s code. Of course our code is perfect, and we would never write a buffer overflow or issue that would be solved by memory safety. But I find consistently that other people seem to, and then I’m forced to contribute to the same code base.
- ignoramous 3y agoGP isn't wrong though. There genuinely are total hell codebases. Not everyone is as dedicated to their craft like Mozart was. There are levels. And some teams and individuals do indeed produce better outcomes because not only they know how but also show how.
- resonious 3y agoWhat kind of solution would you propose to folks like your boss? One positive aspect I see about "rewrite it in Rust" is that you can to some degree expect a random Rust project to not leak and crash and expose vulnerabilities quite as much as a random C++ project. It's silly, but "written in Rust" acts somewhat as a badge of safety and performance, whereas "written in Java" and "written in C++" each only carry one of the two. Of course, developer skill is also huge. You can write slow Rust code or fast Java code, yadda yadda.
- CraigJPerry 3y ago>> What kind of solution would you propose to folks like your boss? How do you want to play this boss? I can see you’re focussing more on the bigger picture and the code is just a means to an end, given that, how about you delegate technical leadership on the codebase to me to let you focus on the product & commercial aspects? If no - maybe words come back to the effect of “it’s my pet/child, how very dare you” yadda yadda - then I can’t see a happy path beyond “thanks for the opportunity, all the best for the future” but there’s certainly room for many mediocre outcomes short of parting ways if that’s preferred. If yes - “hey, we don’t have infinite money and we prob can’t afford to hire the help to do this to a gold standard so how about we agree these commercial milestones (once change delivery falls below X days on average, or once feature Y that you always wanted lands in prod, or once the defect rate drops below Z per week etc etc) - I get bonus $$$”
- Const-me 3y ago> What kind of solution would you propose to folks like your boss? Rewrite it in C#. It’s safer than Rust, because VM. Both standard and third party libraries are often way better. With modern versions of the language, GC allocations are avoidable if that’s what needed for performance reasons. C interop is equally simple.
- pjmlp 3y agoNot necessarily VM, depending on how it gets deployed.
- tuna74 3y agoCould you expand on how to avoid using GC in C#?
- pjmlp 3y agoValue types (structs), stack allocated arrays, spans, native memory allocation, arenas. You can also enable the warnings/errors that complain about missing using declarations for class and structs with the Dispose pattern.
- eklavya 3y agoI am yet to see someone who can't make memory safety mistakes in C++. You might want to start a tutorial series on how to do that. If this skill can be taught that is, and isn't genetic.
- fsckboy 3y agoi don't make memory safety errors in C or C++. i'd recommend embracing hungarian naming (if you call it apps-hungarian you've not embraced it fully enough, read older documentation) and be as rigid as rust about using it. i-, c-, p-, and Max are your best friends, don't declare one of those without declaring all the others that you will need. using hungarian, adopt naming conventions about Open/Close, Init/Finish, Alloc/Free, Start/End, Alpha/Omega, or whatever, and apply them rigidly to any class/struct (with indentation that's obvious). When you put in an Open, you go and put the Close in at that moment, just as you would close any paren you opened. don't return from all over the place in a function, goto endblock and free what needs freeing, you need to work on autopilot not thinking through the twists and turns to play monte carlo with getting it right. If you are going to return an allocation, your name needs to be Open, Init, etc. Use whatever words you want, but it's got to be something that makes you as the caller think "this is an open paren, i need to close it" using ifdef debug type mechanisms, hook malloc and free and put guard word asserts at the beginning and end of every allocation, and magic number ids and reference counts in all structs, and hook main() and exit() so you check those for leaks. all. the. time. work in a systematic way that avoids problems and make that your priority, everything else like functionality is slaved to that.
- eklavya 3y agoI should take this to the security team although I have a hunch that they'll think I am full of shit. What with the CVE count never going down with asan, ubsan, tsan and all kinds of guidelines, analyzers, tests and what not.
- Conscat 3y agoHungarian notation has never been proven to reduce errors compared to strong types, and the CppCoreGuidelines tell you not to use it. clang-tidy can largely automate Hungarian notation, at least.
- oaw-bct-ar-bamf 3y agoIt might not help you today with your immediate problem but think about it this way: You become the boss or responsible for some product. If you decide at the beginning to start off using Rust or rewrite some ancient, unmaintained library using Rust, then you prevent people like your cowboy developer to mess stuff up with this category of faults. Either you would not hire him in the first place because he never came to grips with Rust so you only end up with developers on your team that understand and actively chose the tradeoffs that Rust offers.
- foobarian 3y agoIf the cowboy developer is the boss they can still just wrap everything in unsafe blocks. But I think I'd take that over the C++ new/delete/malloc/free salad.
- orangeboats 3y agoAt least `unsafe` blocks tend to raise other people's eyebrows rather quickly. The word itself is telling you to take a double take after all. Some rather "questionable" C/C++ code can, and are missed during code review sessions. One could put the blame on code reviewers, but let's be honest, code reviewing is a mindnumbing task for many of us.
- keyle 3y agoPlease write a book about this. I'd want to read it!
- zozbot234 3y ago> I still don't need rust because I don't code like a crazy person. This is not a foolproof argument because safety problems can easily result from unforeseen interactions among parts of the code that all seem to be OK and not "crazy" locally. A significant benefit of something like the borrow checker is that it can suss out these problematic interactions in a comprehensive way, even at the cost of forbidding some code patterns that would be perceived as safe in most cases. (Idiomatic use of Rust then requires you to either rewrite such code or stick it in an unsafe block and figure out what the preconditions are for it to be used safely.)
- fl7305 3y agoI'm new to Rust, but wouldn't it be possible for the "C++ boss" to start writing Rust code like below? Here I think we have a multi-threading race condition that can lead to a crash (?) use std::sync::Arc; use std::thread; use std::time::Duration; fn main() { let shared_data = Arc::new(42); // Create an Arc let weak_ref = Arc::downgrade(&shared_data); // Create a Weak reference let thread_handle = thread::spawn(move || { // Simulate some work println!("Thread Data: {}", shared_data); thread::sleep(Duration::from_millis(10)); // The Arc is dropped at the end of this thread }); // Give the other thread a little time to start up (this is part of the race condition) thread::sleep(Duration::from_millis(10)); // Try to upgrade the Weak reference and unwrap directly in the print statement println!("Weak Data: {}", weak_ref.upgrade().unwrap()); // Wait for the other thread to finish thread_handle.join().unwrap(); }
- ColonelPhantom 3y agoSure, that does seem to be a race condition that can crash. I'm not sure how valuable this example is though, because it's not very intricate at all: a Weak reference can be invalidated (duh!) The fix is trivial: just use an Arc instead of a Weak. In addition, `upgrade().unwrap()` should be a sizable red flag (like any unwrap, really) since fallibility is kind of the entire thing of Weak.
- 3y ago
- quicknir 3y agoIt's honestly unfortunate that rust has been sold so hard on memory safety, so that when C++ folk don't spend tons of time in memory issues they think rust is pointless. I don't want rust for memory safety. I want it for things like proc macros, a sane module system, a good and accepted error handling system, destructive move, constrained generics, unified static and dynamic polymorphism, language level customization points, and many more things.