average c++ dev
-
But I must o p t i m i z e! ó_ò
Yes, let's spend two hours on figuring out optimal values of preallocating a vector for your specific use-case. It's worth the couple of microseconds saved! Kleinvieh macht auch Mist.
-
You don't need
unsafeto write vulnerable code in rust.Yes I know there are other ways to do it. That's one way.
-
"C++ compilers also warn you..."
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it's compiled?
I've written a little bit of C++ decades ago, and since then I've worked alongside devs who worked on C++ projects. I've never seen a codebase that didn't produce hundreds if not thousands of lines of warnings when compiling.
I work on one of the larger c++ projects out there (20 to 50 million lines range) and though I don't see the full build logs I've yet to see a component that has a warning.
-
Borrow checking...existed in C++ too
Wat? That's absolutely not true; even today lifetime-tracking in C++ tools is still basically a research topic.
...someone found memory bugs in Rust, again, because it is NOT soundly memory safe.
It's not clear what you're talking about here. In general, there are two ways that a language promising soundness can be unsound: a bug in the compiler, or a problem in the language definition itself permitting unsound code. (
unsafechanges the prerequisites for unsoundness, placing more burden on the user to ensure that certain invariants are upheld; if the code upholds these invariants, but there's still unsoundness, then that falls into the "bug in Rust" category, but unsoundness of incorrectunsafecode is not a bug in Rust.)Rust has had both types of bugs. Compiler bugs can be (and are) fixed without breaking (correct) user code. Bugs in the language definition are, fortunately, fixable at edition boundaries (or in rare cases by making a small breaking change, as when the behavior of
extern "C"changed).wrote on last edited by [email protected]Have you heard about cve-rs?
https://github.com/Speykious/cve-rs
Blazingly fast memory failures with no unsafe blocks in pure Rust.
Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity
Edit 2: Before the Cult of Rust
sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I'm not a C absolutist, I am just telling you to be aware of the limitations of your tools -
But does it have cargo-mommy
wrote on last edited by [email protected]https://github.com/Shadlock0133/cargo-vibe
I thought it was a joke, but this is actually viable and even configurable
By default,
cargo-vibewill, on success, vibe full strength for 3 seconds.You can change that by setting
CARGO_VIBE_PATTERNenvironment variable. For
example, to set it vibe for 1.5 second on 20% strength, you can do:CARGO_VIBE_PATTERN="0.2 1.5s" cargo vibe <cmd>You can also set full patterns of vibes to run, by separating them with slashes
/. Here is one example:CARGO_VIBE_PATTERN="0.4 1s/0.6 1s/0.8 0.75s/1.0 0.25s"Wait, there's more! https://github.com/funkeleinhorn/cargo-shock
To let Cargo Shock trigger your shock collar use:
cargo shock buildTo use it everytime you can
alias cargo="cargo shock".Cargo Shock can also be combined with other tools like Cargo Mommy and Cargo Vibe like this:
cargo mommy vibe shock build ...And they have a really slick site: https://openshock.org/
-
That's not what I meant. I understand that rust forces things to be more secure. It's not not like there's some guarantee that rust is automatically safe, and C++ is automatically unsafe.
wrote on last edited by [email protected]I want you to imagine that your comments in this thread were written by an engineer or a surgeon instead of a programmer.
Imagine an engineer saying "Sure, you can calculate the strength of a bridge design based on known material properties and prove that it can hold the design weight, it that doesn't automatically mean that the design will be safer than one where you don't do that". Or "why should I have to prove that my design is safe when the materials could be defective and cause a collapse anyway?"
Or a surgeon saying "just because you can use a checklist to prove that all your tools are accounted for and you didn't leave anything inside the patient's body doesn't mean that you're going to automatically leave something in there if you don't have a checklist". Or "washing your hands isn't a guarantee that the patient isn't going to get an infection, they could get infected some other way too".
A doctor or engineer acting like this would get them fired, sued, and maybe even criminally prosecuted, in that order. This is not the mentality of a professional, and it is something that programming as a profession needs to grow out of.
-
I want you to imagine that your comments in this thread were written by an engineer or a surgeon instead of a programmer.
Imagine an engineer saying "Sure, you can calculate the strength of a bridge design based on known material properties and prove that it can hold the design weight, it that doesn't automatically mean that the design will be safer than one where you don't do that". Or "why should I have to prove that my design is safe when the materials could be defective and cause a collapse anyway?"
Or a surgeon saying "just because you can use a checklist to prove that all your tools are accounted for and you didn't leave anything inside the patient's body doesn't mean that you're going to automatically leave something in there if you don't have a checklist". Or "washing your hands isn't a guarantee that the patient isn't going to get an infection, they could get infected some other way too".
A doctor or engineer acting like this would get them fired, sued, and maybe even criminally prosecuted, in that order. This is not the mentality of a professional, and it is something that programming as a profession needs to grow out of.
"washing your hands isn't a guarantee that the patient isn't going to get an infection, they could get infected some other way too".
Every single doctor should know this yes.
It seems people are adding a sentence I didn't say "rust can be unsafe and thus we shouldn't try" on top of the one I did say "programmers should be aware that rust doesn't automatically mean safe".
-
"washing your hands isn't a guarantee that the patient isn't going to get an infection, they could get infected some other way too".
Every single doctor should know this yes.
It seems people are adding a sentence I didn't say "rust can be unsafe and thus we shouldn't try" on top of the one I did say "programmers should be aware that rust doesn't automatically mean safe".
wrote on last edited by [email protected]Then you should probably be a little more explicit about that, because I have never, not once in my life, heard someone say "well you know wearing a seatbelt doesn't guarantee you'll survive a car crash" and not follow it up with "that's why seatbelts are stupid and I'm not going to wear one".
-
Then you should probably be a little more explicit about that, because I have never, not once in my life, heard someone say "well you know wearing a seatbelt doesn't guarantee you'll survive a car crash" and not follow it up with "that's why seatbelts are stupid and I'm not going to wear one".
wrote on last edited by [email protected]We need to stop attaching shit someone doesn't say to something they did. It makes commutating hostile and makes you an asshole.
Edit: okay that was a bit rude. But it's so frustrating to say something and then have other people go "that means <this other thing you didn't say>!!!11!"
-
"C++ compilers also warn you..."
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it's compiled?
I've written a little bit of C++ decades ago, and since then I've worked alongside devs who worked on C++ projects. I've never seen a codebase that didn't produce hundreds if not thousands of lines of warnings when compiling.
Ideally? Zero. I'm sure some teams require "warnings as errors" as a compiler setting for all work to pass muster.
In reality, there's going to be odd corner-cases where some non-type-safe stuff is needed, which will make your compiler unhappy. I've seen this a bunch in 3rd party library headers, sadly. So it ultimately doesn't matter how good my code is.
There's also a shedload of legacy things going on a lot of the time, like having to just let all warnings through because of the handful of places that will never be warning free. IMO its a way better practice to turn a warning off for a specific line.. Sad thing is, it's newer than C++ itself and is implementation dependent, so it probably doesn't get used as much.
-
100%. In my opinion, the whole "build your program around your model of the world" mantra has caused more harm than good. Lots of "best practices" seem to be accepted without any quantitative measurement to prove it's actually better. I want to think it's just the growing pains of a young field.
Even with qualitative measurements they can do stupid things.
For work I have to write code in C# and Microsoft found that null reference exceptions were a common issue. They actually calculated how much these issues cost the industry (some big number) and put a lot of effort into changing the language so there's a lot of warnings when something is null.
But the end result is people just set things to an empty value instead of leaving it as null to avoid the warnings. And sure great, you don't have null reference exceptions because a value that defaulted to null didn't get set. But now you have issues where a value is an empty string when it should have been set.
The exception message would tell you exactly where in the code there's a mistake, and you'll immediately know there's a problem and it's more likely to be discovered by unit tests or QA. Something that's an value that's supposed to be set may not be noticed for a while and is difficult to track down.
So their research indicated a costly issue (which is ultimately a dev making a mistake) and they fixed it by creating an even more costly issue.
There's always going to be things where it's the responsibility of the developer to deal with, and there's no fix for it at the language level. Trying to fix it with language changes can just make things worse.
-
Have you heard about cve-rs?
https://github.com/Speykious/cve-rs
Blazingly fast memory failures with no unsafe blocks in pure Rust.
Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity
Edit 2: Before the Cult of Rust
sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I'm not a C absolutist, I am just telling you to be aware of the limitations of your toolsSo now we're considering bugs in the compiler as bugs in the language?
-
So now we're considering bugs in the compiler as bugs in the language?
wrote on last edited by [email protected]A) Rust doesn't have a formal specification other than "whatever the fuck our team hallucinated in this compiler version"
B) Doesn't matter the definition if it fucks your day because you're not careful.
Sure sure Heil Rust but be mindful of the fuck you're doing before you get bit ¯\_ (ツ) _/¯
-
We need to stop attaching shit someone doesn't say to something they did. It makes commutating hostile and makes you an asshole.
Edit: okay that was a bit rude. But it's so frustrating to say something and then have other people go "that means <this other thing you didn't say>!!!11!"
wrote on last edited by [email protected]I understand your frustration and I apologize for reading into your comments something you didn't mean. I, too, wish people would say what they mean and mean what they say, and that when you say something its taken to mean what you said.
Unfortunately very often people will make a very reasonable (even factually true) point as a preamble to support something very unreasonable. If you agree with the reasonable point the person will then act like you agree with the unreasonable one. This is not only more time consuming and tiring to argue against, it also lends a great deal more credibility to the unreasonable point than it is really owed. To the uninformed reader to looks like the two sides of the argument partially agree, when nothing could be further from the truth. Its immensely frustrating to have your words used against you like this, so many people try and preempt it by jumping straight to (what they assume to be) the unreasonable point and arguing against it directly.
This is toxic for actual discussion. It means that good faith actors have to add all sorts of qualifications and clarifications about where they stand before they say anything about anything, which is tiring in itself. But its the world that we live in. If someone makes an unqualified comment about the CO2 emissions of volcanoes in a thread about anthropogenic climate change people are going to assume that they don't think climate change is real. And, operating that way, those people will be right more often than they're wrong.
-
Have you heard about cve-rs?
https://github.com/Speykious/cve-rs
Blazingly fast memory failures with no unsafe blocks in pure Rust.
Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity
Edit 2: Before the Cult of Rust
sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I'm not a C absolutist, I am just telling you to be aware of the limitations of your toolsYeah, and that falls under the first category, bugs in the compiler: https://github.com/rust-lang/rust/issues/25860
(All exploits in that repo are possible due to that bug.)
-
Yeah, and that falls under the first category, bugs in the compiler: https://github.com/rust-lang/rust/issues/25860
(All exploits in that repo are possible due to that bug.)
Yeah and those are the ones currently identified (btw that issue isn't completely fixed) because rust never was nor advertised itself as sound. Meaning, you gotta be careful when writing Rust code too. Not as much as C++, but it's not a magical shield against memory problems like people have been shilling it as.
-
A) Rust doesn't have a formal specification other than "whatever the fuck our team hallucinated in this compiler version"
B) Doesn't matter the definition if it fucks your day because you're not careful.
Sure sure Heil Rust but be mindful of the fuck you're doing before you get bit ¯\_ (ツ) _/¯
wrote on last edited by [email protected]Rust doesn’t have a formal specification other than “whatever the fuck our team hallucinated in this compiler version”
That's simply not true. The Reference, while not an ISO-style formal spec, does actually specify most of the intended language behavior, and incrementally approaches completion over time. But even if you insist on an ISO-style formal spec, there's Ferrocene: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/
it fucks your day because you’re not careful
The
cve-rsvulnerability is actually not really something you'd ever write by accident. Also note that the bug report has multiple versions because, even though a "full" solution is pending some deeper compiler changes, the firsttwothree versions of the exploit are now caught by the compiler. So, like I said, the compiler bugs do get fixed over time. -
"C++ compilers also warn you..."
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it's compiled?
I've written a little bit of C++ decades ago, and since then I've worked alongside devs who worked on C++ projects. I've never seen a codebase that didn't produce hundreds if not thousands of lines of warnings when compiling.
0 in our case, but we are pretty strict. Same at the first place I worked too. Big tech companies.
-
I mostly see warnings when compiling source code of other projects. If you get a warning as a dev, it's your responsibility to deal with it. But also your risk, if you don't. I made it a habit to fix every warning in my own projects. For prototyping I might ignore them temporarily. Some types of warnings are unavoidable sometimes.
If you want to make yourself not ignore warnings, you can compile with
-Werrorif using GCC/G++ to make the compiler a pedantic asshole that doesn't compile until you fix every fucking warning. Not advisable for drafting code, but definitely if you want to ship it.Except when you have to cast size_t on int and vice versa (for "small" numbers). I hate that warning.
-
Structs with union members that allow the same place in memory to be accessed either word-wise, byte-wise, or even bit-wise are a god-sent for everyone who needs to access IO-spaces, and I'm happy my C-compiler lets me do it.
#pragma push
