4 ms·

That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on

That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on the other hand doesn't fail. It has 3 things equivalent to nil or Null. Called undefined and NaN and NULL. It lets you do some nutty things with undefined. undefined + 1 = NaN. NaN + 1 = NaN. NULL + 1 = 1. In python None + 1 is an instant hard crash. Still these types of errors are traceable by following the code path and even easier with a debugger. For C++ a seg fault could trigger an error anywhere and there's no direct path to the source of the error. For nullptr it triggers a runtime error but this is the same problem as javascript... not a huge deal. In terms of safety the order is: Python, Javascript, C++. C++ alone with the segfaults is what causes it to be on the bottom of the list despite the extensive type system. One seg fault alone is worse then a python program with 20 type errors due to the fact about how hard it is to trace seg faults. There are C++ production code bases where known segfaults exist but no one has ever been able to find the offending line.

_gabe_ 4y ago
I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.
- deltaonefour 4y ago
  >I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.
  - _gabe_ 4y ago
    I completely agree with all your points except for the fact that tracing a segfault is harder than tracing an undefined object in JS. JavaScript will happily chug along with an undefined object and do random stuff as well. It may not throw any errors or warnings, and you'll only realize something is wrong because your app is behaving weirdly. This is the same problem as a C++ segfault. 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). This doesn't mean I'm advocating everyone abandon safe languages :) I haven't had a chance to try out a language like Rust, but I definitely want to give it a try at some point. Safe languages are trying to solve specific self induced headaches which is awesome. A couple other languages I'm very interested in are Odin and Jai. Anyways, language safety is a great goal, but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning (and again, yes, I know a safer language avoids those footguns by default :)
    - deltaonefour 4y ago
      >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.
MrJohz 4y ago
It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safety of the language, and more to do with the IEEE 754 spec on floating point numbers. For example, `math.nan + 1` in Python should equal NaN as well. While NaN technically is a kind of null, it's one embedded in the spec for floating point numbers, and therefore present in every language that uses them, including far safer languages like Rust. It's also worth noting that neither language has the behaviour described in this article, which is that doing anything to a null (not NaN) value returns a new null value. In Python, there are a handful of allowed operations on `None` (such as converting it to a string), and everything else will return an error. Javascript is somewhat more lenient, in that it allows type coercion, so in a numeric context, `null` will first be converted to 0, and `undefined` will first be converted to NaN. Likewise, in the presence of other strings, these values will be coerced to string values. However, if you attempt to access attributes on these objects, call methods on them, or pass them to methods that don't accept null values, then they will throw errors. This is the big difference to a language like Objective C.
- deltaonefour 4y ago
  Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.
  - MrJohz 4y ago
    Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).

_gabe_ 4y ago

I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.

deltaonefour 4y ago
>I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.
- _gabe_ 4y ago
  I completely agree with all your points except for the fact that tracing a segfault is harder than tracing an undefined object in JS. JavaScript will happily chug along with an undefined object and do random stuff as well. It may not throw any errors or warnings, and you'll only realize something is wrong because your app is behaving weirdly. This is the same problem as a C++ segfault. 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). This doesn't mean I'm advocating everyone abandon safe languages :) I haven't had a chance to try out a language like Rust, but I definitely want to give it a try at some point. Safe languages are trying to solve specific self induced headaches which is awesome. A couple other languages I'm very interested in are Odin and Jai. Anyways, language safety is a great goal, but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning (and again, yes, I know a safer language avoids those footguns by default :)
  - deltaonefour 4y ago
    >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.

MrJohz 4y ago

It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safety of the language, and more to do with the IEEE 754 spec on floating point numbers. For example, `math.nan + 1` in Python should equal NaN as well. While NaN technically is a kind of null, it's one embedded in the spec for floating point numbers, and therefore present in every language that uses them, including far safer languages like Rust. It's also worth noting that neither language has the behaviour described in this article, which is that doing anything to a null (not NaN) value returns a new null value. In Python, there are a handful of allowed operations on `None` (such as converting it to a string), and everything else will return an error. Javascript is somewhat more lenient, in that it allows type coercion, so in a numeric context, `null` will first be converted to 0, and `undefined` will first be converted to NaN. Likewise, in the presence of other strings, these values will be coerced to string values. However, if you attempt to access attributes on these objects, call methods on them, or pass them to methods that don't accept null values, then they will throw errors. This is the big difference to a language like Objective C.

deltaonefour 4y ago
Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.
- MrJohz 4y ago
  Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).