5 ms·

>JavaScript will happily chug along with an undefined object and do random stuff as well. Javascripts behavior is not random. The exception thrown by an undefi

>JavaScript will happily chug along with an undefined object and do random stuff as well. Javascripts behavior is not random. The exception thrown by an undefined object is deterministic meaning you run the program again with the SAME input parameters the program will crash at the same point. The only time it could be random is if you have time as input or a random number generator that effects the logic. Additionally the undefined can be traced backwards logically by following the datapath to the source. You can do this by reading code or setting break points in the code and looking at the state along each step. Both of the above DO not happen in an out of bounds memory error. A segfault may not even occur. Your program can run and nothing can happen. Then suddenly your program can run and then segfault at a random location. The segfault happens randomly and at random locations and there is no direct datapath that leads to the source. >And coding styles absolutely have a role to play in how safe a language is. A good developer can work just as efficiently in C or C++ as they can in something like Rust. Especially if they've built tooling to catch nasty bugs like heap corruption or memory leaks (which takes a couple hours at most). I don't think you have much experience with C++ if you're unaware how much harder debugging a segfault is than an undefined. Modern C++ doesn't need additional tooling and you can definitely stay within the bounds of features introduced in C++11 and above for safety, this is trivial and easily done. However segfaults can still creep in via libraries or other entry ways. This occurs especially for extremely large code bases. >but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning Have you worked on large codebases with hundreds of developers? Even when every developer attempts to follow good practices or always uses smart pointers, eventually just via statistics some C++ foot gun accidentally goes off. You are infinitely better off in a language where the foot gun doesn't even exist. Additionally some apis and writing really optimized code requires use of foot guns. Many safety features like smart pointers just have too high of a performance overhead so we avoid and use archaic stuff like 'new'. CUDA for example doesn't allow you to use the std and introduces new foot guns such as dereferencing a device pointer on a host device. You can get around this by wrapping device pointers in a special device type but again this is overhead and the safety abstractions are not zero cost. Safety has a performance cost and making this performance cost as small as possible is why C++ is the way it is.

_gabe_ 4y ago
You seem to be missing the forest for the trees. > I don't think you have much experience with C++ if you're unaware how much harder debugging a segfault is than an undefined. I love how developer's go to argument is, "you must not be very experienced if you've never encountered X". It's gatekeepy and gross. I have had plenty of experience with C++, including maintaining a large corporate application in C++ professionally. I have had nasty segfaults. Remember, I was qualifying my statements with how "I program in C++ as a hobby" these days, which means I have complete control over how much unsafe C++ code I allow in my codebase. It turns out you can avoid most segfaults using a little forethought and planning, like I said. > Have you worked on large codebases with hundreds of developers? Yes, and it's gross. I worked on a 20 year old legacy C++ application that dealt with high frequency trading at my old job. It was nasty and there were several problems including a very large memory leak that was untraceable. You seem to have missed what I said, which was "but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning". Key words, "a good _developer_". Once you throw in hundreds of developers into the mix all bets are off, and that's not the claim I was making. If you're dealing with a system that you know inside and out, it is usually a very simple matter to trace a segfault. There are a lot of things that you can do to avoid untraceable segfaults, some of which you've alluded to. Use modern C++ safety constructs, things like `vector.at(i)` instead of `vector[i]` if you don't know if `i` is going to be in bounds. That is what I'm alluding too. If a solo developer codes with some simple forethought and planning, segfaults are not a big deal. JavaScript undefined objects can be just as difficult to trace, under the assumption that you're a solo developer in C++ using good practices. Yes you can place breakpoints and try to figure out where the error occurs. You can do the same thing with a C++ segfault. The hard part is figuring out where the error occurs, which I believe we agree on. I know what you're saying about a segfault occuring at random times, but for the hundredth time, if you're following good practices, segfaults can be as predictable as a JavaScript undefined object. There's a qualification there, which is if you're following best practices. Anyways, I hope you have a good day :). My intent is not to have an argument over an inconsequential problem, so I'm done replying. I hope I've made myself clear, I'm not trying to argue that C++ is better, or that segfaults are the same exact thing as JavaScript undefined objects. All I'm saying is that both are difficult things to debug, and if you're coding by yourself, you can use a few safety features (using built-in constructs, handrolled tools, or third party apps, I don't care what you use) to make a segfault no worse than a JS undefined object.

_gabe_ 4y ago

You seem to be missing the forest for the trees. > I don't think you have much experience with C++ if you're unaware how much harder debugging a segfault is than an undefined. I love how developer's go to argument is, "you must not be very experienced if you've never encountered X". It's gatekeepy and gross. I have had plenty of experience with C++, including maintaining a large corporate application in C++ professionally. I have had nasty segfaults. Remember, I was qualifying my statements with how "I program in C++ as a hobby" these days, which means I have complete control over how much unsafe C++ code I allow in my codebase. It turns out you can avoid most segfaults using a little forethought and planning, like I said. > Have you worked on large codebases with hundreds of developers? Yes, and it's gross. I worked on a 20 year old legacy C++ application that dealt with high frequency trading at my old job. It was nasty and there were several problems including a very large memory leak that was untraceable. You seem to have missed what I said, which was "but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning". Key words, "a good _developer_". Once you throw in hundreds of developers into the mix all bets are off, and that's not the claim I was making. If you're dealing with a system that you know inside and out, it is usually a very simple matter to trace a segfault. There are a lot of things that you can do to avoid untraceable segfaults, some of which you've alluded to. Use modern C++ safety constructs, things like `vector.at(i)` instead of `vector[i]` if you don't know if `i` is going to be in bounds. That is what I'm alluding too. If a solo developer codes with some simple forethought and planning, segfaults are not a big deal. JavaScript undefined objects can be just as difficult to trace, under the assumption that you're a solo developer in C++ using good practices. Yes you can place breakpoints and try to figure out where the error occurs. You can do the same thing with a C++ segfault. The hard part is figuring out where the error occurs, which I believe we agree on. I know what you're saying about a segfault occuring at random times, but for the hundredth time, if you're following good practices, segfaults can be as predictable as a JavaScript undefined object. There's a qualification there, which is if you're following best practices. Anyways, I hope you have a good day :). My intent is not to have an argument over an inconsequential problem, so I'm done replying. I hope I've made myself clear, I'm not trying to argue that C++ is better, or that segfaults are the same exact thing as JavaScript undefined objects. All I'm saying is that both are difficult things to debug, and if you're coding by yourself, you can use a few safety features (using built-in constructs, handrolled tools, or third party apps, I don't care what you use) to make a segfault no worse than a JS undefined object.