3 ms·

C# also solved the nullability problem after the fact. It integrates well with the "?." operator also found in Typescript.

dexwiz 2y ago
Optional chaining is now in vanilla JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- KronisLV 2y ago
  This is really pleasant, when combined with the nullish coalescing operator: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... const isStatusValid = myStore.someObject?.isStatusValid ?? false; (e.g. if some data is not initialized along the way, or you put in some new object which just isn't meant to have that field but some related logic needs to check for it)
neonsunset 2y ago
Yup, it is Kotlin-style nullability analysis that is a default everywhere now. The last place that does not have ideal behavior is System.Text.Json, but that is fixable with a flag, maybe two, and there are edge cases where static analysis can't see through some expressions and assumes null so you have to specify it isn't with '!'. Nonetheless, works great with '??', '??=' expressions, required fields/props and pattern matching. From practical standpoint, a project with Nullable: enable, WarningsAsErrors: nullable has almost never have to think about unexpected nulls again - a solved problem.
devjab 2y ago
Having nullability has its own set of issues. I prefer explicit error handling to null checks. That being said, I don’t think there is really that much of a difference in that you might use Interface as a JS Any sort of thing in Go (it’s obviously difference), and where you would deal with nil pointers is often where you would perform a null check anyway. I prefer the go style of doing a check every time rather than some of the time with the risk of missing a time. Or on the flip-side simply defining your own default. I know that a lot of people like how C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. It’s mostly down to opinion and preference. So I don’t think you can really call it a “problem” as such. Having nullability will be a feature to some, and not having it will be a feature to others. I think both decisions were right for their respective languages. C# needs it for its close integration with mssql and its exception handling. Go doesn’t want it because it favours simplicity in types and direct error handling.
- masklinn 2y ago
  > Having nullability has its own set of issues. I prefer explicit error handling to null checks. Nullability does not preclude explicit checks. In fact it requires them. Which Go currently does not: you can dereference any pointer or use any interface and it will blow in your face if either is nil. > C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. That literally makes no sense. The entire point of moving checks to the compiler is that it catches developer errors upstream and prevents them. > C# needs it for its close integration with mssql and its exception handling. That's a nonsensical just-so story. Go on, explain how Haskell or Swift or Zig have explicit nullability for their close integration with mssql and exception handling (and while at it, do explain the relationship between exception handling and nullability)

dexwiz 2y ago

Optional chaining is now in vanilla JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

KronisLV 2y ago
This is really pleasant, when combined with the nullish coalescing operator: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... const isStatusValid = myStore.someObject?.isStatusValid ?? false; (e.g. if some data is not initialized along the way, or you put in some new object which just isn't meant to have that field but some related logic needs to check for it)

neonsunset 2y ago

Yup, it is Kotlin-style nullability analysis that is a default everywhere now. The last place that does not have ideal behavior is System.Text.Json, but that is fixable with a flag, maybe two, and there are edge cases where static analysis can't see through some expressions and assumes null so you have to specify it isn't with '!'. Nonetheless, works great with '??', '??=' expressions, required fields/props and pattern matching. From practical standpoint, a project with Nullable: enable, WarningsAsErrors: nullable has almost never have to think about unexpected nulls again - a solved problem.

devjab 2y ago

Having nullability has its own set of issues. I prefer explicit error handling to null checks. That being said, I don’t think there is really that much of a difference in that you might use Interface as a JS Any sort of thing in Go (it’s obviously difference), and where you would deal with nil pointers is often where you would perform a null check anyway. I prefer the go style of doing a check every time rather than some of the time with the risk of missing a time. Or on the flip-side simply defining your own default. I know that a lot of people like how C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. It’s mostly down to opinion and preference. So I don’t think you can really call it a “problem” as such. Having nullability will be a feature to some, and not having it will be a feature to others. I think both decisions were right for their respective languages. C# needs it for its close integration with mssql and its exception handling. Go doesn’t want it because it favours simplicity in types and direct error handling.

masklinn 2y ago
> Having nullability has its own set of issues. I prefer explicit error handling to null checks. Nullability does not preclude explicit checks. In fact it requires them. Which Go currently does not: you can dereference any pointer or use any interface and it will blow in your face if either is nil. > C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. That literally makes no sense. The entire point of moving checks to the compiler is that it catches developer errors upstream and prevents them. > C# needs it for its close integration with mssql and its exception handling. That's a nonsensical just-so story. Go on, explain how Haskell or Swift or Zig have explicit nullability for their close integration with mssql and exception handling (and while at it, do explain the relationship between exception handling and nullability)