6 ms·

I don’t buy that null is a billion dollar mistake. Just because some dude with a fancy name said so doesn’t mean it’s true. In particular, how many dollars do

I don’t buy that null is a billion dollar mistake. Just because some dude with a fancy name said so doesn’t mean it’s true. In particular, how many dollars does it cost to have null safety, and how many more does it cost to use it? I feel like folks quoting Hoare never even bother asking this question.

chomp 4y ago
null itself isn’t the billion dollar mistake, it’s that literally every object can be T|null. Undefined or null is actually quite useful, as long as you’re expecting it.
- disintegore 4y ago
  Null safety means you can't dereference a null pointer. Therefore something like `T | null` is not possible, because `null` doesn't exist. What you'd have instead is an Option or Maybe type and a compiler that requires exhaustive handling of it.
  - masklinn 4y ago
    In the informal context of GP’s comment, null is a singleton type whose sole value is null. That exact syntax (modulo langage divergences) is one of the options for “nullable” in Python: https://docs.python.org/3/library/typing.html#typing.Optional https://docs.python.org/3/library/typing.html#typing.Optiona...
    - disintegore 4y ago
      Which can still lead to unrecoverable runtime errors, that could otherwise be compilation errors.
      - masklinn 4y ago
        What are you talking about?
        disintegore 4y ago
        I'm talking about the fact that nullable types do not on their own guarantee null safety and that these two things are not equivalent.
        masklinn 4y ago
        That's about as unclear as your previous comment, at best. At worst, it's just wrong. The typechecker would only allow on the union operations which are allowed on both types, anything beyond that would first have to use type checks or assertions in order to split the union. So, again, what are you talking about?
        disintegore 4y ago
        That's actually a good point. I made assumptions about the meaning of the term `null` that can't be true in every language that uses it. There are some exceptions to the behaviour you describe, like for instance with C# which for the longest time only allowed value types to be annotated as nullable, and only very recently extended this to reference types, and only as an opt-in feature, and the type checker only throws warnings, etc. That would be a case of a language which is not "null safe" but provides faculties for accomplishing that.
- Tade0 4y ago
  Seems like an easy fix. At least in languages like TypeScript: https://www.typescriptlang.org/tsconfig#strictNullChecks https://www.typescriptlang.org/tsconfig#strictNullChecks
  - KMag 4y ago
    Yes, null safety is a very simple change to type systems and type checkers. Unfortunately, there's a lot of cultural momentum in this regard.
- pizlonator 4y ago
  That’s not necessarily a mistake. Claiming that a reference cannot be null means that if you later realize it has to be, you’ve got a potentially compat-breaking refactoring to make. So, nullable-by-default is either a good idea or a bad idea depending on lots of complex reasons.
  - Lewton 4y ago
    That's the exact same issue you run into if you suddenly find out that you need to use a different type (because.. Yeah, that's exactly what it means). That doesn't mean you should default to writing all your code without types
mhzsh 4y ago
There is a cost to pay up-front in having null safety in your codebase, but the savings come back over time. Can we easily measure whether or not it truly makes a difference? Maybe not, but I'm jaded enough to gladly pay that cost, knowing I can think about whether or not something is null once, versus having to forever wonder if the complicated code I need to interact with is going to bite me later.
mlfreeman 4y ago
I've come to the conclusion that in the generic business software world, removing null would be a trillion dollar mistake. Instead of applications simply crashing, millions of hours would be wasted trying to clean up bogus values (e.g. "changeme", empty string, etc) from databases and calculate what should have been there instead.
- eat_veggies 4y ago
  do you see this a lot in industry codebases written in languages that have null safety?
- jgilias 4y ago
  I think you misunderstand what null safety really means. It’s not that values can’t be null/None/Empty. It’s just that it’s made explicit where this is the case and where it’s not the case. Without null safety everything is implicitly maybe null.
  - KMag 4y ago
    In other words, the problem is that null is treated as if its class is a subclass of all classes. All of a sudden, you've introduced a superset of all of the problems with multiple inheritance. (Nulltype inherits from everything!) You've also made it nearly impossible to adhere to the Liskov substitution principle (unless none of your classes can do anything, making all object instances equivalent at runtime). In type theory, a type that is a supertype of all types is called a "top type" and a type that is a subtype of all types is a "bottom type". It's okay to have one or more bottom types in a type system, as long as it's not possible to create instances of them. Unfortunately, in most of the popular statically typed languages, null is an instance of a bottom type. One reasonable use of a bottom type would be to allow a variable to assume one of many types, and require a dynamically-checked upcast when actually passing that variable to a function that cared about its types.
- anonyme-honteux 4y ago
  Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under the sun. What Kotlin & cie are saying is that if your parameter is a RandomGenerator, null should not be allowed there because null is not a RandomGenerator. Null is null and that's it. If you search something in a map, your value will be of type "String?", that is "String | null" and that's completely fine, the compiler will assist you with that too.
DougBTX 4y ago
> how many more does it cost to use it? The null-safe language I've used the most is Rust. It is far from the hardest part of the language to learn, but the biggest impact day-to-day is that when constructing a new object, initial values for all the non-nullable fields have to be provided all-at-once. You can't have a constructor which is passed a `this` object full of nulls then fill in all the values later, instead the object is constructed whole in a single operation. Otherwise the explicit distinction between T and Maybe T just makes life easier.
- pohuing 4y ago
  Ironically you can do that in dart. If you declare your member late and never initialise it you can run into what amount to a null reference exception.
disintegore 4y ago
The more I think about it, the more it sounds like hubris. If Tony Hoare hadn't made that design choice then somebody else somewhere would have. I think the sentiment behind the quote and its widespread use is correct however. It definitely does seem like the tradeoffs of null safety are worth it in the vast majority of cases. Most of us who use GC languages with massive runtimes sacrifice a lot more performance for a lot less value.
- masklinn 4y ago
  > If Tony Hoare hadn't made that design choice then somebody else somewhere would have. Not necessarily. If Hoare had not used null references he might have invented nullables to fill the need and others would have replicated that.
  - disintegore 4y ago
    I am supposing that the further back in time you go, the more likely it is that simplicity and performance would influence language and compiler design. As opposed to developer experience. I think this can be supported by the fact that these fancy language features have been successfully implemented for decades and are only now showing up in mainstream languages.
    - masklinn 4y ago
      > the more likely it is that simplicity and performance would influence language and compiler design. Neither "simplicity" nor "performance" were huge factors in Algol's design.
      - deleted 4y ago
        [deleted]
  - syrrim 4y ago
    He invented it for algol, a language with sufficient complexity that it was basically impossible to implement. The process of creating c involved stripping off everything but the most necessary features. Null references made it, nullable types likely wouldn't have.
coldtea 4y ago
>In particular, how many dollars does it cost to have null safety Close to none. >Just because some dude with a fancy name said so doesn’t mean it’s true. The dude is responsible for tons of what we take for granted. He is also the one who invented the null pointer, so there's that. I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name". He didn't sit to calculate the money in damages from it's use - it was more of a figure of speech and a guess ("probably"). But it's very likely that the prodictivity losses from null errors, the consequences for security, program downtime, and so on, could trivially have costed 1 billion dollar in damages over the years - actually much more. A single null error in one of the space code responsible from bringing down a NASA mission, could easily cost close to a billion itself. In fact the memory safety industry (e.g. static analyzers and in memory analyzing tools), safety checks for nulls by consultants, and so on, industry easily has have 1 billion in profits over the last 40 years, so there's that...
- pizlonator 4y ago
  > Close to none so zero dollars were spent adding null safety to languages? False. Zero dollars were spent converting code to those languages? False. Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. > I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name". Sounds like a crappy way to reason about facts. Just because he did cool shit once upon a time doesn’t mean that we should believe him when he pulls numbers out of his ass.
  - IshKebab 4y ago
    "close to none" is not the same as "zero". But yes, converting Dart code to null safety is not very difficult.
    - pizlonator 4y ago
      “Not very difficult” is not the same thing as “close to no cost”
armchairhacker 4y ago
Billion dollar mistake? No But anecdotally I've experienced many null-pointer runtime errors, to the point where I very strongly believe having strict or even half-decent null checking reduces the amount of runtime errors my code produces non-negligibly. I'm sure not everyone has the same experience, but I strongly prefer languages with null safety (AKA marking a type "non-null", and then the compiler makes a good effort to ensure it's not null).
- hajile 4y ago
  At 100k per year, 1B is a mere 10,000 man-years or with 4.4M devs in the US, that's less than one work day per currently-working dev across their entire career. I'm sure that I've spent weeks worth of time doing this in one form or another and I doubt that I'm alone here. By that metric, it's more like the 100B mistake.
  - LarsDu88 4y ago
    Well said!
moomin 4y ago
Here's my take: yes, it was a billion dollar mistake. But it wasn't null on its own that was the mistake, it was making it impossible to opt out of. It's incalculable how much that breaks pretty much all of the mental modelling you do about systems. Null safety is the only way to get back to where we want to be.
- KMag 4y ago
  I believe that's why Hoare said that the null reference, not null, was his billion dollar mistake. It was a simple one-liner in his type checker "if getting a type error in a cast, if the source type is nulltype and the target type is any kind of reference, always let the cast happen". His (biased by hindsight) recollection is that he even felt it was a bit dirty at the time, but made a lot of code shorter.
- darthrupert 4y ago
  I always thought of it as a humblebrag. Like, I made this billion dollar mistake while giving birth to a trillion dollar industry.
  - moomin 4y ago
    You’re not wrong.
hota_mazi 4y ago
You are correct. The billion dollar mistake was not null, it's languages that have a null value but don't support nullability in their type system. Kotlin and Swift get this right.
swader999 4y ago
He was wrong on this but just in the amount. A billion dollars isn't that much these days.
deleted 4y ago
[deleted]
KMag 4y ago
I don't think Hoare said that null was his mistake. I believe he said that the null reference was his mistake. In other words, null is not a reference, and treating null as a reference in all contexts conflates optionality and referentiality. The problem is that referentiality and optionality should be orthogonal concepts in type systems. Nullability/optionality is clearly useful. References/pointers are clearly useful. The problem is making them a single concept in a type system, thus requiring all references/pointers to be nullable and making it very awkward (such as forcing the user to manually declare a wrapper type holding a boolean and the wrapped value) to have optional values without making them references. The conflation of referentiality and optionality in the most popular static type systems also bleeds over into mental shortcuts used by many programmers in dynamically typed languages when thinking about the types of parameters expected by functions/methods. Had Algol W, C, etc. kept optionality and referentiality separate in their type systems, I think Python/Ruby/Lisp etc. programmers would likely think more carefully when passing None into fuctions/methods.
- kazinator 4y ago
  Lisp doesn't have None; it has nil. The Lisp nil was not inspired by the conflation of referentiality and optionality in popular static type systems. It predates them.
  - KMag 4y ago
    The conjecture about dynamically typed languages was regarding the cultural effect of the popularity non-null-safe static type systems on the current practice of coding in dynamic programming languages. It wasn't a conjecture about the structure of the type systems in those dynamically typed languages.
    - kazinator 4y ago
      I find that even less plausible. I don't suspect that the null reference practices in, say Java, have any influence on the way people work in Lisp. Optional parameters in Lisp take on a value of nil when the argument is omitted (unless a different default is specified). Various search functions return nil when an item is not found: find, member, gethash, ... The practices around these conventions may, at times, resemble work in static languages with null references, but there is no cause-and-effect there.
satvikpendem 4y ago
After using languages with the Option type [0] and exhaustive pattern matching [1] (OCaml was my first exposure), I can definitely say that bare null pointers, without using the prior two things I mentioned, are a mistake. It's not that null as a concept is a mistake, since a Option type has both Some and None, it's that in most mainstream languages, people have to implicitly deal with them rather than having the compiler checking it for them explicitly. And if the computer can check our work for us, why do we have to do it ourselves? That's why it leads to mistakes and is why it's called a billion dollar mistake, because I'm sure at least 1 billion (possibly even 1 trillion) dollars worth of manpower, lost revenue and time have been spent dealing with nulls. [0] https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type [1] https://en.wikipedia.org/wiki/Standard_ML#Pattern_matching https://en.wikipedia.org/wiki/Standard_ML#Pattern_matching
- deleted 4y ago
  [deleted]
ajkjk 4y ago
Yeah if anything it's way more than that.
vbezhenar 4y ago
I agree. I write Java for many years and never had I any particular issue with nulls. I used Kotlin for a while and null-safety is a compromise which often leads to verbose and unnecessary code. I don't have any particular side on this battle, I can use both approaches. I just don't think that it's a big deal.

chomp 4y ago

null itself isn’t the billion dollar mistake, it’s that literally every object can be T|null. Undefined or null is actually quite useful, as long as you’re expecting it.

disintegore 4y ago
Null safety means you can't dereference a null pointer. Therefore something like `T | null` is not possible, because `null` doesn't exist. What you'd have instead is an Option or Maybe type and a compiler that requires exhaustive handling of it.
- masklinn 4y ago
  In the informal context of GP’s comment, null is a singleton type whose sole value is null. That exact syntax (modulo langage divergences) is one of the options for “nullable” in Python: https://docs.python.org/3/library/typing.html#typing.Optional https://docs.python.org/3/library/typing.html#typing.Optiona...
  - disintegore 4y ago
    Which can still lead to unrecoverable runtime errors, that could otherwise be compilation errors.
    - masklinn 4y ago
      What are you talking about?
      - disintegore 4y ago
        I'm talking about the fact that nullable types do not on their own guarantee null safety and that these two things are not equivalent.
        masklinn 4y ago
        That's about as unclear as your previous comment, at best. At worst, it's just wrong. The typechecker would only allow on the union operations which are allowed on both types, anything beyond that would first have to use type checks or assertions in order to split the union. So, again, what are you talking about?
        disintegore 4y ago
        That's actually a good point. I made assumptions about the meaning of the term `null` that can't be true in every language that uses it. There are some exceptions to the behaviour you describe, like for instance with C# which for the longest time only allowed value types to be annotated as nullable, and only very recently extended this to reference types, and only as an opt-in feature, and the type checker only throws warnings, etc. That would be a case of a language which is not "null safe" but provides faculties for accomplishing that.
Tade0 4y ago
Seems like an easy fix. At least in languages like TypeScript: https://www.typescriptlang.org/tsconfig#strictNullChecks https://www.typescriptlang.org/tsconfig#strictNullChecks
- KMag 4y ago
  Yes, null safety is a very simple change to type systems and type checkers. Unfortunately, there's a lot of cultural momentum in this regard.
pizlonator 4y ago
That’s not necessarily a mistake. Claiming that a reference cannot be null means that if you later realize it has to be, you’ve got a potentially compat-breaking refactoring to make. So, nullable-by-default is either a good idea or a bad idea depending on lots of complex reasons.
- Lewton 4y ago
  That's the exact same issue you run into if you suddenly find out that you need to use a different type (because.. Yeah, that's exactly what it means). That doesn't mean you should default to writing all your code without types

mhzsh 4y ago

There is a cost to pay up-front in having null safety in your codebase, but the savings come back over time. Can we easily measure whether or not it truly makes a difference? Maybe not, but I'm jaded enough to gladly pay that cost, knowing I can think about whether or not something is null once, versus having to forever wonder if the complicated code I need to interact with is going to bite me later.

mlfreeman 4y ago

I've come to the conclusion that in the generic business software world, removing null would be a trillion dollar mistake. Instead of applications simply crashing, millions of hours would be wasted trying to clean up bogus values (e.g. "changeme", empty string, etc) from databases and calculate what should have been there instead.

eat_veggies 4y ago
do you see this a lot in industry codebases written in languages that have null safety?
jgilias 4y ago
I think you misunderstand what null safety really means. It’s not that values can’t be null/None/Empty. It’s just that it’s made explicit where this is the case and where it’s not the case. Without null safety everything is implicitly maybe null.
- KMag 4y ago
  In other words, the problem is that null is treated as if its class is a subclass of all classes. All of a sudden, you've introduced a superset of all of the problems with multiple inheritance. (Nulltype inherits from everything!) You've also made it nearly impossible to adhere to the Liskov substitution principle (unless none of your classes can do anything, making all object instances equivalent at runtime). In type theory, a type that is a supertype of all types is called a "top type" and a type that is a subtype of all types is a "bottom type". It's okay to have one or more bottom types in a type system, as long as it's not possible to create instances of them. Unfortunately, in most of the popular statically typed languages, null is an instance of a bottom type. One reasonable use of a bottom type would be to allow a variable to assume one of many types, and require a dynamically-checked upcast when actually passing that variable to a function that cared about its types.
anonyme-honteux 4y ago
Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under the sun. What Kotlin & cie are saying is that if your parameter is a RandomGenerator, null should not be allowed there because null is not a RandomGenerator. Null is null and that's it. If you search something in a map, your value will be of type "String?", that is "String | null" and that's completely fine, the compiler will assist you with that too.

DougBTX 4y ago

> how many more does it cost to use it? The null-safe language I've used the most is Rust. It is far from the hardest part of the language to learn, but the biggest impact day-to-day is that when constructing a new object, initial values for all the non-nullable fields have to be provided all-at-once. You can't have a constructor which is passed a `this` object full of nulls then fill in all the values later, instead the object is constructed whole in a single operation. Otherwise the explicit distinction between T and Maybe T just makes life easier.

pohuing 4y ago
Ironically you can do that in dart. If you declare your member late and never initialise it you can run into what amount to a null reference exception.

disintegore 4y ago

The more I think about it, the more it sounds like hubris. If Tony Hoare hadn't made that design choice then somebody else somewhere would have. I think the sentiment behind the quote and its widespread use is correct however. It definitely does seem like the tradeoffs of null safety are worth it in the vast majority of cases. Most of us who use GC languages with massive runtimes sacrifice a lot more performance for a lot less value.

masklinn 4y ago
> If Tony Hoare hadn't made that design choice then somebody else somewhere would have. Not necessarily. If Hoare had not used null references he might have invented nullables to fill the need and others would have replicated that.
- disintegore 4y ago
  I am supposing that the further back in time you go, the more likely it is that simplicity and performance would influence language and compiler design. As opposed to developer experience. I think this can be supported by the fact that these fancy language features have been successfully implemented for decades and are only now showing up in mainstream languages.
  - masklinn 4y ago
    > the more likely it is that simplicity and performance would influence language and compiler design. Neither "simplicity" nor "performance" were huge factors in Algol's design.
    - deleted 4y ago
      [deleted]
- syrrim 4y ago
  He invented it for algol, a language with sufficient complexity that it was basically impossible to implement. The process of creating c involved stripping off everything but the most necessary features. Null references made it, nullable types likely wouldn't have.

coldtea 4y ago

>In particular, how many dollars does it cost to have null safety Close to none. >Just because some dude with a fancy name said so doesn’t mean it’s true. The dude is responsible for tons of what we take for granted. He is also the one who invented the null pointer, so there's that. I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name". He didn't sit to calculate the money in damages from it's use - it was more of a figure of speech and a guess ("probably"). But it's very likely that the prodictivity losses from null errors, the consequences for security, program downtime, and so on, could trivially have costed 1 billion dollar in damages over the years - actually much more. A single null error in one of the space code responsible from bringing down a NASA mission, could easily cost close to a billion itself. In fact the memory safety industry (e.g. static analyzers and in memory analyzing tools), safety checks for nulls by consultants, and so on, industry easily has have 1 billion in profits over the last 40 years, so there's that...

pizlonator 4y ago
> Close to none so zero dollars were spent adding null safety to languages? False. Zero dollars were spent converting code to those languages? False. Zero dollars were spent solving problems uniquely created by not having the benefits of null? Also false. > I'd take his expert opinion and experience on the matter over anybody referring to him as "a dude with a fancy name". Sounds like a crappy way to reason about facts. Just because he did cool shit once upon a time doesn’t mean that we should believe him when he pulls numbers out of his ass.
- IshKebab 4y ago
  "close to none" is not the same as "zero". But yes, converting Dart code to null safety is not very difficult.
  - pizlonator 4y ago
    “Not very difficult” is not the same thing as “close to no cost”

armchairhacker 4y ago

Billion dollar mistake? No But anecdotally I've experienced many null-pointer runtime errors, to the point where I very strongly believe having strict or even half-decent null checking reduces the amount of runtime errors my code produces non-negligibly. I'm sure not everyone has the same experience, but I strongly prefer languages with null safety (AKA marking a type "non-null", and then the compiler makes a good effort to ensure it's not null).

hajile 4y ago
At 100k per year, 1B is a mere 10,000 man-years or with 4.4M devs in the US, that's less than one work day per currently-working dev across their entire career. I'm sure that I've spent weeks worth of time doing this in one form or another and I doubt that I'm alone here. By that metric, it's more like the 100B mistake.
- LarsDu88 4y ago
  Well said!

moomin 4y ago

Here's my take: yes, it was a billion dollar mistake. But it wasn't null on its own that was the mistake, it was making it impossible to opt out of. It's incalculable how much that breaks pretty much all of the mental modelling you do about systems. Null safety is the only way to get back to where we want to be.

KMag 4y ago
I believe that's why Hoare said that the null reference, not null, was his billion dollar mistake. It was a simple one-liner in his type checker "if getting a type error in a cast, if the source type is nulltype and the target type is any kind of reference, always let the cast happen". His (biased by hindsight) recollection is that he even felt it was a bit dirty at the time, but made a lot of code shorter.
darthrupert 4y ago
I always thought of it as a humblebrag. Like, I made this billion dollar mistake while giving birth to a trillion dollar industry.
- moomin 4y ago
  You’re not wrong.

hota_mazi 4y ago

You are correct. The billion dollar mistake was not null, it's languages that have a null value but don't support nullability in their type system. Kotlin and Swift get this right.

swader999 4y ago

He was wrong on this but just in the amount. A billion dollars isn't that much these days.

deleted 4y ago

[deleted]

KMag 4y ago

I don't think Hoare said that null was his mistake. I believe he said that the null reference was his mistake. In other words, null is not a reference, and treating null as a reference in all contexts conflates optionality and referentiality. The problem is that referentiality and optionality should be orthogonal concepts in type systems. Nullability/optionality is clearly useful. References/pointers are clearly useful. The problem is making them a single concept in a type system, thus requiring all references/pointers to be nullable and making it very awkward (such as forcing the user to manually declare a wrapper type holding a boolean and the wrapped value) to have optional values without making them references. The conflation of referentiality and optionality in the most popular static type systems also bleeds over into mental shortcuts used by many programmers in dynamically typed languages when thinking about the types of parameters expected by functions/methods. Had Algol W, C, etc. kept optionality and referentiality separate in their type systems, I think Python/Ruby/Lisp etc. programmers would likely think more carefully when passing None into fuctions/methods.

kazinator 4y ago
Lisp doesn't have None; it has nil. The Lisp nil was not inspired by the conflation of referentiality and optionality in popular static type systems. It predates them.
- KMag 4y ago
  The conjecture about dynamically typed languages was regarding the cultural effect of the popularity non-null-safe static type systems on the current practice of coding in dynamic programming languages. It wasn't a conjecture about the structure of the type systems in those dynamically typed languages.
  - kazinator 4y ago
    I find that even less plausible. I don't suspect that the null reference practices in, say Java, have any influence on the way people work in Lisp. Optional parameters in Lisp take on a value of nil when the argument is omitted (unless a different default is specified). Various search functions return nil when an item is not found: find, member, gethash, ... The practices around these conventions may, at times, resemble work in static languages with null references, but there is no cause-and-effect there.

satvikpendem 4y ago

After using languages with the Option type [0] and exhaustive pattern matching [1] (OCaml was my first exposure), I can definitely say that bare null pointers, without using the prior two things I mentioned, are a mistake. It's not that null as a concept is a mistake, since a Option type has both Some and None, it's that in most mainstream languages, people have to implicitly deal with them rather than having the compiler checking it for them explicitly. And if the computer can check our work for us, why do we have to do it ourselves? That's why it leads to mistakes and is why it's called a billion dollar mistake, because I'm sure at least 1 billion (possibly even 1 trillion) dollars worth of manpower, lost revenue and time have been spent dealing with nulls. [0] https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type [1] https://en.wikipedia.org/wiki/Standard_ML#Pattern_matching https://en.wikipedia.org/wiki/Standard_ML#Pattern_matching

deleted 4y ago
[deleted]

ajkjk 4y ago

Yeah if anything it's way more than that.

vbezhenar 4y ago

I agree. I write Java for many years and never had I any particular issue with nulls. I used Kotlin for a while and null-safety is a compromise which often leads to verbose and unnecessary code. I don't have any particular side on this battle, I can use both approaches. I just don't think that it's a big deal.