4 ms·

> It’s crazy how Rust just gets rid of this whole class of bugs As do TypeScript, and Kotlin, and Dart, and Python (with MyPy), and C#, and Swift... It's hone

> It’s crazy how Rust just gets rid of this whole class of bugs As do TypeScript, and Kotlin, and Dart, and Python (with MyPy), and C#, and Swift... It's honestly inexcusable that Go, as a relatively new statically-typed language, doesn't have strict null-checks

tticvs 5y ago
Unfortunately it's easy enough to confuse MyPy that you can't really fit in with the rest of this list.
rowanG077 5y ago
Unfortunately in any real world typescript or python the type checking is almost always partial. Which means it doesn't actually save you from these kind of errors.
- cageface 5y ago
  I have not found this to be the case in Typescript code I've worked on. The main issue I've found with TS is stuff coming in from outside the system as JSON that doesn't conform to expected formats.
  - CryZe 5y ago
    One issue I've noticed is that indexing into a T[] array where T can't be undefined, results in the expression to be of type T, not T | undefined, despite an out of bounds index evaluating to undefined. I believe I've seen that they recently added a setting that changes this though.
    - cageface 5y ago
      A lot of statically typed languages leave array indexing as a loophole for convenience but yeah this can also be a source of errors.
  - andy_ppp 5y ago
    Consider using https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts to help with that...
  - jakelazaroff 5y ago
    You can solve the JSON issue by validating that it deserializes to a known type at the point of ingress. I wrote a small library that I use in basically every project to help with that: https://www.npmjs.com/package/narrows https://www.npmjs.com/package/narrows
mbStavola 5y ago
I don't know about C# and Swift, but Kotlin, Python, and Typescript are only null-safe-ish; there is always a relatively easy path to smuggling a null value into your program regardless of the guarantees of the types you use. This isn't to say it's useless, just that it's not as useful as it _could_ be. I've seen codebases in all three languages where there have been real production issues due to null values, even though the type decls say otherwise. Kotlin probably does the best job here but using any JVM library introduces potential (K)NPEs.
- unscaled 5y ago
  This situation is unfortunately quite hard to avoid in the languages above since they either added null safety (or indeed any kind of type-checking) at a later stage (C# and Python) or they need to maintain compatibility with a language or platform that is not null-safe (Kotlin with Java, Swift with Objective C, TypeScript with JavaScript). Languages like Rust, Haskell or ML do not have this issue since they do not need to support such a legacy layer.
  - pjmlp 5y ago
    Kind of true, there is still the possibility to smuggle null values via unsafe, or FFI, but then the fault is on whoever certified the code as safe.
    - unscaled 5y ago
      I was hesitating whether to mention unsafe code blocks or FFI, but the no language that gets thing done can avoid abuse of its escape hatches. Even Haskell has to deal with nulls when doing FFI.
- wildbook 5y ago
  As much as I like C#, your points apply to it too.
- skohan 5y ago
  How can you get an unchecked nil into a swift program without the unsafe API?
andy_ppp 5y ago
As someone working on a Typescript codebase with "string? | undefined" everywhere I wish this were true.
virgilp 5y ago
C# only sort-of-fixed this problem and it did so rather inelegantly IMO. E.g. nullable types are not options - you can't "map" them (you can't invoke Select, Where etc). It's easy to "get value or default" (via operator `??`), but you can't do the other, equally frequent thing, of "apply transformation on value if not-null". Or... well, you can, but here's the syntax: var newVal = val == null ? (resultType?) null : compute(val.Value); instead of var newVal = val.Select(compute);
- CodesInChaos 5y ago
  For that I use my own extension function like `?.Map(x => ...)`, defined as `Map(this T input, Func<T, TResult> map) => map(input)`. Still a bit ugly, but much nicer than the ternary operator. Of course that doesn't fix all the other issues with null handling in C# (inconsistency between null references and null value types, inability to nest options, ...)
- mathw 5y ago
  Various bits of C# and its libraries also variously ignore non-nullability when it suits them. I know it's done the way it's done for compatibility reasons, but it's really quite confusing around the edges as a result. And despite something being non-nullable in the code it could still be null at runtime thanks in my experience particularly to the joys of deserialisation libraries.

tticvs 5y ago

Unfortunately it's easy enough to confuse MyPy that you can't really fit in with the rest of this list.

rowanG077 5y ago

Unfortunately in any real world typescript or python the type checking is almost always partial. Which means it doesn't actually save you from these kind of errors.

cageface 5y ago
I have not found this to be the case in Typescript code I've worked on. The main issue I've found with TS is stuff coming in from outside the system as JSON that doesn't conform to expected formats.
- CryZe 5y ago
  One issue I've noticed is that indexing into a T[] array where T can't be undefined, results in the expression to be of type T, not T | undefined, despite an out of bounds index evaluating to undefined. I believe I've seen that they recently added a setting that changes this though.
  - cageface 5y ago
    A lot of statically typed languages leave array indexing as a loophole for convenience but yeah this can also be a source of errors.
- andy_ppp 5y ago
  Consider using https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts to help with that...
- jakelazaroff 5y ago
  You can solve the JSON issue by validating that it deserializes to a known type at the point of ingress. I wrote a small library that I use in basically every project to help with that: https://www.npmjs.com/package/narrows https://www.npmjs.com/package/narrows

mbStavola 5y ago

I don't know about C# and Swift, but Kotlin, Python, and Typescript are only null-safe-ish; there is always a relatively easy path to smuggling a null value into your program regardless of the guarantees of the types you use. This isn't to say it's useless, just that it's not as useful as it _could_ be. I've seen codebases in all three languages where there have been real production issues due to null values, even though the type decls say otherwise. Kotlin probably does the best job here but using any JVM library introduces potential (K)NPEs.

unscaled 5y ago
This situation is unfortunately quite hard to avoid in the languages above since they either added null safety (or indeed any kind of type-checking) at a later stage (C# and Python) or they need to maintain compatibility with a language or platform that is not null-safe (Kotlin with Java, Swift with Objective C, TypeScript with JavaScript). Languages like Rust, Haskell or ML do not have this issue since they do not need to support such a legacy layer.
- pjmlp 5y ago
  Kind of true, there is still the possibility to smuggle null values via unsafe, or FFI, but then the fault is on whoever certified the code as safe.
  - unscaled 5y ago
    I was hesitating whether to mention unsafe code blocks or FFI, but the no language that gets thing done can avoid abuse of its escape hatches. Even Haskell has to deal with nulls when doing FFI.
wildbook 5y ago
As much as I like C#, your points apply to it too.
skohan 5y ago
How can you get an unchecked nil into a swift program without the unsafe API?

andy_ppp 5y ago

As someone working on a Typescript codebase with "string? | undefined" everywhere I wish this were true.

virgilp 5y ago

C# only sort-of-fixed this problem and it did so rather inelegantly IMO. E.g. nullable types are not options - you can't "map" them (you can't invoke Select, Where etc). It's easy to "get value or default" (via operator `??`), but you can't do the other, equally frequent thing, of "apply transformation on value if not-null". Or... well, you can, but here's the syntax: var newVal = val == null ? (resultType?) null : compute(val.Value); instead of var newVal = val.Select(compute);

CodesInChaos 5y ago
For that I use my own extension function like `?.Map(x => ...)`, defined as `Map(this T input, Func<T, TResult> map) => map(input)`. Still a bit ugly, but much nicer than the ternary operator. Of course that doesn't fix all the other issues with null handling in C# (inconsistency between null references and null value types, inability to nest options, ...)
mathw 5y ago
Various bits of C# and its libraries also variously ignore non-nullability when it suits them. I know it's done the way it's done for compatibility reasons, but it's really quite confusing around the edges as a result. And despite something being non-nullable in the code it could still be null at runtime thanks in my experience particularly to the joys of deserialisation libraries.