Quote:
I disagree that marking potentially unsafe code as 'unsafe' is the same as making the programmer jump through hoops. It informs the compiler that it should not issue errors or warnings about potentially dangerous instructions in the code and it tells humans reading the source code that here is something which is known to be unsafe, yet necessary, and that (hopefully) care has been taken to cover all possible points of failure manually.
O_o
To be blunt, I'd be a fool to think you'd see the hoops I see. You are obviously, as stated even, thinking Rust as solving the problems of the C++ language. You don't see the issue as "hoop jumpery" because you see the issue as a solution. Of course, everyone defends their own designs with the great "Solution" label. ([Edit]For the jerks, I am including myself in the subset of "everyone".[/Edit]) You started this discussion on a C/C++ board. You are responsible for making the argument if you want me to see what I see as "hoop jumpery" as a solution; you can't just say you disagree because you don't think of as "hoop jumpery".
Quote:
I feel like you're saying that all of the added correctness and abstraction that the Rust memory management system affords the programmer, is collectively worth less than the ability to write unsafe code without the hassle of having to mark it unsafe.
I intended no such thing. You've taken one example, an example offered to clarify a general point, to stretch into the absurd.
I'll make the explanation, after a fashion, more exact.
Rust offers $(Programmer) the $(Feature) feature. The Rust feature $(Feature) is conflicting with designs $(Programmer) intends to use to solve a problem. $(Programmer) does not want that feature. $(Programmer) must disable that feature. $(Programmer) has to spend time disabling that feature. Rust does not now offer feature $(Feature) because $(Programmer) have disabled that feature. $(Programmer) can now use Rust to solve the problem.
$(Language) does not have $(Feature) feature. $(Programmer) does not have to spend time disabling feature $(Feature). $(Programmer) can spend all the time available to solve the problem.
[Edit]
The above is also an explanation of why Rust has no chance whatsoever to actually replace C.
[/Edit]
I, personally, like the guarantees that take place during program compilation, but one of the reasons I prefer C++ so much is that I enjoy a lot of different fields. I often need to "push metal", and I don't want the tools stopping me. The tools I have are intended to help me. Every hour I spend fighting my tools is time I don't have for solving my problems. (I can't help but say, this sort of thing is why I don't do "Linux From Scratch" anymore. I enjoyed the experience, but I spent way more time "developing" the system than actually using the system.) I can't justify jumping through hoops when other tools don't make me jump through those hoops.
As above, I'd be a fool to think you'd see the same hoops. C++ has a lot of hoops. (The "available by default" exception mechanism in C++ has caused a lot of issues, and many new C++ programmers are terribly fooled by the apparent option to ignore exceptions.) You like those Rust features being "available by default"? Awesome. I have no doubt then that you'd see plenty of "hoop jumpery" in my C++ code. You may indeed be able to say that "You do what you want, where you want, how you want, and Rust mostly stays out of your way.".
Quote:
The way i see it, our tools will never improve if we are not willing to make mistakes. C++ no longer represents the best we can do when it comes to systems programming languages, let us reiterate, make some mistakes and hopefully end up with a better tool in the end.
o_O
Your argument is missing one crucial ingredient: if you don't learn from the mistakes, you don't get the better tool.
Yes. Developing "yet another post C++ language" on the foundations of C++ is a mistake.
Quote:
What i see is a third option, somewhere between the C approach and the GC approach, where the language is designed in a way to make the compiler help us avoid memory flaws in the program.
My libraries and applications have thousands of lines of code dedicated to various "firewalls". (In other words, my libraries are "designed in a way to make the compiler help us avoid memory flaws in the program".) I've spent years throwing my code at dozens of compilers. (Literally every line of library code I've written in the last three years has passed through at least five compilers.) I run my code through "Valgrind". I write dozens of automated tests. I exhaustively--aka "all possible inputs"--test as much code as possible. I branch test every other bit of code. Every flaw that lives in my code is because I made the sort of mistakes that don't get discovered until the moon aligns and someone slaughters a goat. My code doesn't have the sort of flaws that Rust could prevent.
No. I don't consider that "hoop jumpery". Well, I do consider that "hoop jumpery", but I do that because I care about quality. I'd run my Rust code, if I used Rust, through a similar process.
Quote:
You should join the bandwagon, we have a great view and cocktails with little umbrellas in them!
I hate to burst your bubble, but I consider Python and Javascript better than Rust. I know the legends say "I'm totes into data metap yo!", but I actually just focus on designs that enable "use polymorphism", and Rust isn't as good at "use polymorphism" as those language.
If I were to join a different bandwagon, I'd probably push for proposed changes to Python sooner rather than later so I could just keep using what I've learned the last several months. To be clear though, I have focused on Python for the last several months, and I hope the caretakers make such changes. I have no qualms about leaving C++ behind for a language with less "hoop jumpery".
Soma