benrazdev's comments

why does an RSS feed aggregator even need ads in the first place?

I'll never forget walking through a tech store and seeing a HP printer that advertised itself as being "AI-powered". I don't know how you advertise a printer to make it exciting to customers but this is just ridiculous. I'm glad that tech companies are finally finding out people won't magically buy their product if they call it AI-powered.

My best guess is that the font I am using (WOFF2 variable font) might be tripping up the browser.

I agree with your point in general, but I would challenge the idea that tuples aren't something that is intuitive to explain (even in less than 30 seconds). Perhaps it's difficult to explain why tuples and not lists, but that's also relatively simple (homogeneous vs heterogeneous)

Its not really a matter of logic, I guess.

Writing `pub` is personally more annoying to me than writing `if err != nil`. I understand that most people don't like how capitalization determines visibility, but I think it actually makes sense when you think about it.

I can't speak for other Rust programmers but I can speak for myself.

I obviously enjoy programming Rust and I like many of the choices it made, but I am well aware of the tradeoffs Rust has made and I understand why other languages chose not to make them. Nor do I think Rust functions equally as well in every single use case.

I imagine most Rust users think like this, but unfortunately there seems to be a vocal minority who hold very dogmatic views of programming who have shaped how most people view the Rust community.

Technically, with generics, you could get a Result that is almost as good as Rust, but it is unidiomatic and awkward to write:

    type Result[T, E any] struct {
        Val   T
        Err   E
        IsErr bool
    }

    type Payload string

    type ProgError struct {
        Prog   string
        Code   int
        Reason string
    }

    func DoStuff(x int) Result[Payload, ProgError] {
        if x > 8 {
            return Result[Payload, ProgError]{Err: ProgError{Prog: "ls", code: 1, "no directory"}}
        }
        return Result[Payload, ProgError]{Val: "hello"}
    }

>that is, all the information that would be present in a typical Rust error handling scenario as well --- is encoded in the type tree of the errors.

it's only present when you downcast though?

From what the comments are saying I think you downcast with `errors.As` and then work on the underlying error type. But I don't know for sure.

>No enums? [...] We're stuck with magic numbers?

In go you don't strictly need magic numbers because you can define constants:

    type Status int
    const (
        IoProblem Status = iota // we start at zero and go down from there
        JsonParse
        ...
    )

The problem is that there is no exhaustiveness with these constant groups. The type Number is not a closed set of just IoProblem and JsonParse like an enum in C. It is just an int.

Correct me if I am wrong, but does it not mean that they are type-erased though? The whole point of returning an interface is to perform type-erasure.

If I have

    struct S { X int }
    func (s *S) Error() string { ... }

but I return it as an error:

    func DoStuff() error

Then all the caller gets is an error interface. Without downcasting (`.(T)`/`errors.As`), you can only compare it to other instances (if the library author provided them) or see the string representation.

>this is false.

It's mostly false.

Technically, if you use `fmt.Errorf`, then the caller can't get anything useful out of your errors.

Types are promises. All the `error` interface promises is a string representation. I acknowledge that most of the time there is more information available. However, from the function signature _alone_, you wouldn't know. I understand that this is more of a theoretical problem then a practical problem but it still holds (in my opinion).

>> difficulty of writing if err != nil >Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era)

I agree with you. I don't have problems with the `if err!=nil` syntax.

From my post: > It’s become something of a meme to bemoan the supposed difficulty of writing if err != nil. I actually won’t make that point because I think it is a very surface level point that has been talked about to death and *I don’t think the ‘verbosity’ of this code snippet is such an issue.*

I apologize if my language was ambiguous on whether or whether not I had a problem with that syntax.

>In his example author could easily use his `progError` type instead.

I agree, but it was my impression that type erasure was more idiomatic. I should have made it clear that I was criticizing that idiom, not the language.

>Well, no. See for wrap/unwrap functionality https://go.dev/blog/go1.13-errors

You are right. I should have done my research on that before writing that point. I still think that downcasting isn't the most elegant solution because it defeats the point of using the opaque return type but I agree that it is nowhere near as much of a problem as I thought it was.

My understanding is that using `error` as a return type performs type erasure and that the only information given to the caller is the value of the `e.Error()` function. I now understand that this isn't the case.

Thanks for all of the comments!

I want to clarify that I think very highly of Go as a language. I think it gets most things right. It's hard to introduce an abstraction into a language while still making sure that it's not abused. Rust's trait and type system, while powerful have been abused to create some absolutely incomprehensible and long types. Go, on the other hand, doesn't suffer from this issue. If I was too harsh against Go, that was certainly a mistake.

I think that the criticisms of my section on error handling are, for the most part, spot on. My impression was that type erasure for errors was the idiomatic solution, which is patently untrue. When writing the blog post, I was unaware of the functions in the `errors` module as well as the syntactic sugar and general acceptance of downcasting errors. While I would still maintain that Rust errors are more convenient to work with, I must admit that there really isn't any good excuse for my ignorance on this.

When it comes to enums, I stand by my statements on them.

I still believe that it is useful to restrict the values a type might have. And no, I am not using the term enum to mean a rust-style "enum" (tagged union). I am talking about classical enums, more or less as they appear in C.

As an aside, I am not terribly surprised that my website doesn't work well on some browsers. I hacked together the website including the HTML and CSS a couple of years ago and some of the hacks I used I ought to be ashamed of.