[9rx]

> Good luck? Have you done basic programming with rust?

Have you? I am sorry that the good luck did not shine upon you. With the types remaining intact, I modified the (pseudo)code:

    match getFile(fileName) {
         Some(file) => do someghing
         Error => do something else unintended
    }

It still compiles. You failed.

> The thing with the match operator is that the program DOES not compile if you do not handle both SOME and ERROR.

But as you come off your hubris, you can now see above it will compile even when you screw up the error handling. So you haven't gained anything. You still need to write tests to ensure that you are actually doing the right thing. And once you've ensured you are doing the right thing, how do you think crashes are going to go beyond that? Right. Not going to happen.

> Fuzz testing is something our start up doesn't have time for.

Testing, is testing, is testing. If you have time to write tests, you have time to write fuzz tests where they are appropriate. To throw a test out the window just because it has a slightly different execution model (as provided by the language; not something you have to build yourself) is bizarre. In fact, in your case it seems it could have supplanted the other tests you wrote, actually saving you time not only while writing the code, but also later when you had to waste time dealing with the issue. Time clearly isn't as constrained as you let on.

> For golang you can handle the Some and then it crashes if there's a problem. You aren't required to explicitly handle it.

Technically, in Go 'Some' should always be valid, regardless of whether or not there is an error. That is a fundamental feature of the Go language. Given (T, error), the values are not dependent. You don't need to explicitly handle the error. That is a huge misunderstanding. The same would not be true in Rust, which does consider them to be dependent by design, but Go is a completely different language. You can't think Go as being Rust with different syntax. There is a lot more to languages than the superficial.

[ninetyninenine]

>Have you? I am sorry that the good luck did not shine upon you. With the types remaining intact, I modified the (pseudo)code:

Your modification makes no sense. "do something else unintended" Wtf does that even mean? What are you doing? Why don't you spell it out? Because in golang you can do this:

     v, err := getFile(fileName)
     v.read()

And that's a fucking crash. You understand examples are used to illustrate a point right? And that your example shows you missed the point. Hey why don't I insert some psuedo code called "blow up the earth" in my program and that disproves every point ever made by anyone and I'm right. Genius.

>But as you come off your hubris, you can now see above it will compile even when you screw up the error handling.

Think of it like this. The point I'm illustrating is that in rust, you have to handle an error or the program won't compile. In go, you can forget to handle an error and your program will compile. You're going to have to write a bunch of tests to only POSSIBLY catch a missed error handling case. Understand? I don't think you do.

>Testing, is testing, is testing. If you have time to write tests, you have time to write fuzz tests where they are appropriate. To throw a test out the window just because it has a slightly different execution model (as provided by the language; not something you have to build yourself) is bizarre. In fact, in your case it seems it could have supplanted the other tests you wrote, actually saving you time not only while writing the code, but also later when you had to waste time dealing with the issue. Time clearly isn't as constrained as you let on.

It's not bizarre. It's again, lack of experience from your end. Why do I want to spend time writing generic test code that executes off of fuzzed input? I can write test specific code for specific use cases and that's much faster to write then attempting to write tests that work for generic cases.

Also how about not writing tests all together? I mean that's the best solution right? Honestly not to be insulting here, but it's not at all bizarre that you're not seeing how a better type system is better then tests that check for runtime errors. The root of it is that you're just stupid. Like why jump through a bunch of hoops and just call what I'm saying "bizarre" and just be straight with me. We're both mature right? If I think you're truthfully stupid and you think of me the same, just say it. We can take it. Why dance around it by calling my points "bizarre". No your points aren't "bizarre". They are stupid and wrong.

>Technically, in Go 'Some' should always be valid, regardless of whether or not there is an error.

That's why go is bad. You don't need to handle an error if err is not nil. V will be a nil here. And you know what's the only thing you can do with a nil besides check if it's a nil? Crash the program. Literally. With rust, you can do this:

    match getFile(fileName) {
         Some(file) => do someghing
         Error => {}
    }

and do nothing. Which is the same effect as golang. But rust at least tells you to explicitly watch for it.

>You can't think Go as being Rust with different syntax. There is a lot more to languages than the superficial.

It's not about what I think of the language. It's about the intention of the designers. Go was made for people with not much experience. Straight from the horses mouth. Pike is saying he designed it for you.

>That is a fundamental feature of the Go language.

I think you're kind of not getting it. Seriously like the feature of golang is to allow you to unintentionally crash the program and you think that's a good thing?

   v, err := getFile(fileName)
   doSomething(v)

Take some time to think here. I know you think you're smart, but you need to hit the brakes for a second. Think: What is the purpose of the above code? If err actually is not a nil, and v ends up being a nil. What is the purpose of this type of logic to even exist? Is it for v to crash somewhere in doSomething? Are you saying that a fundamental feature for golang to crash somewhere inside doSomething?

Really think about this. You literally said it's a feature for golang to not handle an actual error and for v to still be "valid." So if err is not nil, v is a nil. What happens here? You think this is a feature? Or are you just not thinking straight? Just pause for a second.

Another thing to help you along: You know the inventor of the null/nil value called it his billion dollar mistake right? Have you thought about why it's a huge mistake? Here's a hint: You can't do anything with a null/nil except check if it's a null or crash the program by using it improperly. The existence of a nil/null signifies the existence of feature that you can only use to crash your program unintentionally.

Why doesn't elm crash? Why is rust safer then most languages? A big part of the reason is both languages don't have nulls or nils. And that doesn't have anything to do with a "complete" type system.

Hopefully you get it now. If not I can't help you.

[9rx]

> Why don't you spell it out?

The earlier comment already spelled it out. Hence why it wished you luck as we knew you would not be able to deliver. Yet right on cue you hilariously tried anyway.

I take that you haven't actually read anything in this discussion? If you have read it, you haven't understood it. Slow down, comprehend before posting. It seems you've become so fixated on telling us how sum types work – something we understood decades ago – that you have missed the forest for the trees.

> Why do I want to spend time writing generic test code that executes off of fuzzed input?

Remember when you mistakenly wrote (p2 - p1 / t2 - t1)? That's why. A complete type system would negate the need for testing there, but if all you have is sum types... There is no difference between a fuzz test and any other test other than the tooling will feed it 'arbitrary' inputs. It is not like they take more time to write or something. Testing is testing is testing.

In fact, it took me like ten seconds to write the fuzz test for your function when I tried it out earlier. This time argument is disconnected from reality. You have 10 seconds to spare to ensure correctness, especially when you admitted to writing a bunch of useless tests instead. One good test would have gone further and saved you time.

> I think you're kind of not getting it.

Let's change that. Consider your code:

   v, err := getFile(fileName)
   doSomething(v)

Presumably your requirements dictate that your code must do something when getFile fails, so you are obviously going to write a test for that scenario. How do you envision that potential crash condition evading the test? The CPU steps through until getFile fails, then checks if you are running a test and if it so it invents a valid file handle, but if it notices you are in production it returns a corrupt file handle and then crashes? That doesn't make any sense. What does make sense to you that explains how your code will pass tests but fail in production?

If what you are struggling to say is that you have no such requirement to deal with the failure so it is unspecified behaviour, and thus you didn't feel the need to write a test for it, all you can do with sum types, to keep the compiler happy, is purposefully panic. It is unspecified behaviour. Anything else but crashing would be nonsensical – something that is true even if it were written in Rust. Is the source of the panic significant?

> Seriously like the feature of golang is to allow you to unintentionally crash the program and you think that's a good thing?

It doesn't matter in practice. When the program is going to do the wrong thing, it makes little difference how it goes about doing it wrong. But if you really have to choose, crashing is better than silently corrupting data, yes. The latter is far more scary.

However, better is to ensure that your program doesn't do the wrong thing in the first place. If you have a complete type system, that's you best bet. But that isn't realistic. No language you are going to encounter in the real world has that. Meaning, prepare to learn how to write tests. They aren't easy to do right, but you're going to have to do it anyway because without a complete type system you have no other choice.

Anything else is running on hopes and prayers. If you honestly believe that hope and prayer is sufficient, then why are you so worried about crashing?

[ninetyninenine]

>Presumably your requirements dictate that your code must do something when getFile fails, so you are obviously going to write a test for that scenario. How do you envision that potential crash condition evading the test? The CPU steps through until getFile fails, then checks if you are running a test and if it so it invents a valid file handle, but if it notices you are in production it returns a corrupt file handle and then crashes? That doesn't make any sense. What does make sense to you that explains how your code will pass tests but fail in production?

Sigh. You said it was a feature. You said v being nil was a feature lol. Now you want to test it to see if it crashes? I'm saying it should be tested, but YOU said it was a feature for golang to always return a valid v. Now I know you're just not aware of what you're talking about.

>If what you are struggling to say is that you have no such requirement to deal with the failure so it is unspecified behaviour, and thus you didn't feel the need to write a test for it, all you can do with sum types, to keep the compiler happy, is purposefully panic. It is unspecified behaviour. Anything else but crashing would be nonsensical – something that is true even if it were written in Rust. Is the source of the panic significant?

I don't need to specify the difference here. You're just being stubborn. You already know that in rust you need to explictly panic vs. golang you can panic mistakenly with a hidden nil. This discussion is over.