im-a-baby

People who hate on projects are those that have never attempted to create something on their own. It's kind of like how the easiest person to sell something to is a salesman. Most people's default reaction to anything is scepticism. People who have tried to create something on their own, and undoubtedly encountered other's scepticism, can skip the apprehensive stage and get to the meat of a project with an open mind.

Europeans use 220V for everything.

Yea, the issue is that nil's in Go are typed. So `err == nil` is checking err against error's nil value, but the value stored in err is *MyError's nil value.

    package main
    
    import "fmt"
    
    type MyError struct{}
    
    func (m *MyError) Error() string {
        return ""
    }
    
    func main() {
        var err error = nil
        var myErr *MyError = nil

        fmt.Println(err == myErr) // this is false
    }

I do eat grape seeds. Apples, the core is too tough. With watermelon, I greatly prefer seedless. Like it’s not even close in terms of taste or texture. I probably eat about 2 whole watermelon a week in the summer time. It’s always a sad day if I accidentally buy a melon with seeds.

Why do countries exist? To protect the interests of the citizens. Water is an important issue

No not using pointers would not solve the issue. The issue is that the specific error implementation type is part of the method signature. If you returned type MyError instead of *MyError, then it would be impossible to return nil from the method because only pointers can be nil.

Yes you could do that, but then you’d lose type info on the error.

Your distinction between user and programmer doesn’t make sense to me. I typed the regex and I typed the config file. Why is a regex syntax error different than a YAML syntax error? Both are irrecoverable errors for my programs.

Generally, returning a typed error in the function signature in Go is very annoying and dangerous. An example why:

    import "fmt"
    
    type MyError struct{}
    
    func (m *MyError) Error() string {
     return ""
    }

    func myFunc() *MyError {
     return nil
    }
    
    func main() {
     var err error
     err = myFunc()
     if err == nil {
      fmt.Println("No Error")
     } else {
      fmt.Println("Error") // This prints
     }
    }

That's very different than your initial statement of: "Many schools of thought believe that it is impossible to prove the absence of something.". Many (all?) schools of thought believe in the law of excluded middle, which makes it possible to prove the absence of many things.

It's pretty trivial to construct negatives that can be proven. E.g. take a solid colored object and prove it's not a specific color. You can prove the negative statement by proving a positive statement about the true color of the object, e.g. by direct observation, measuring the wavelength of emitted light, etc.

Similarly, you could prove a speaker doesn't eavesdrop by proving it performs a finite set of operations, none of which are eavesdropping.

I'm confused. As the article states, the speakers do wake spuriously and record conversations. So the speakers do eavesdrop, even if it's unintentional. The article goes on to say that, even those the speakers do eavesdrop, they don't use the conversation for ad targeting. I find that hard to believe. The speaker doesn't know it's listening erroneously. If I say "Alexa, order sponges," it's totally within the realm of possibility that Amazon shows me advertisements for Dawn dish soap, and I posit this is true for any prompt I give the speaker. This article doesn't add up.

I think it's fine to add syntactic sugar for panic. The standard library already has similar functionality, like regexp.MustCompile. And personally, I've implemented a Must function in many services. E.g. you try to parse a config file during service startup and parsing fails. There is no recourse from such an error. I'm sure I'm not the only one who has implemented such functionality, so why not add it to the language?

Regarding the guard keyword, the author's proposal doesn't make sense. The guard call comes after the function call that produces the error, so it's not clear what is being guarded. I guess it's the error being wrapped in the guard message, but explaining that clearly in plain English is quite hard. I agree that context is important however. But maybe the Go team is finally ready to admit that stack traces are more useful than error messages. I'd be fine to know that, for example, an error occurred opening a file and having the language provide a full stack trace of where the error happened. I can do without the custom crafted error messages.

I believe the point is that quantum computers allow you to manipulate a linear combination of bits, whereas simulating the weather would require non-linear combinations. It's unclear how a QC would help simulate something like that better than a classical computer.