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.
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)
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"}
}
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.
Yes, that's correct. The interface limits what guarantees the caller has about the type without runtime introspection. I don't think that really makes it any harder to handle expected error conditions though, since type assertions return a boolean. eg:
if myErr, ok := err.(MyError); ok {
// handle MyError case
}
...
But you should always expect that there could be errors you don't expect to exhaustively handle with special logic.
