431–440 of 477 posts
Earlier quoted context omitted.
> I'd like to see Go require return values be dealt with or explicitly ignored. Ever use the return value from fmt.Println?
Not usually, but the correct answer would be to either explicitly ignore the unused return values or use APIs that don't return values you don't care about.
_ = fmt.Println("ok") // 1
fmt.Println("ok") // 2
Earlier quoted context omitted.
"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data." In theory, this is a big deal. In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it. A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another fu…
I've ran into bugs multiple times because I ignored an error result, or overwrote the "err" variable and swallowed an error. Errcheck helps a bit. Other languages that have exceptions that bubble up the stack have a few advantages (easier to instrument with monitoring, stack traces and line numbers out of the box) but developers often misuse error handling as flow control
Any reasonable code review process would catch these (very obvious) problems.
Earlier quoted context omitted.
Screen real estate is limited, especially vertical real estate. Compared to languages with saner error handling, I can read approximately 25% as much Go code at once. That's a real cognitive burden when maintaining code or learning your way around a new codebase, which seems especially egregious from a language whose community consistently proselytizes about how the lack of language features is great for maintainabil…
I don't think "screen real estate" is the right argument here. The problem is just that every line creates cognitive load and there's a tradeoff between concision and descriptiveness. A language with piles of syntactic sugar and magic gets it wrong with too much concision and can read like line noise when it gets overused. Go goes the other way though and makes it way too verbose and just makes it difficult to read t…
This expression
let a = x.iter().filter(...).apply(...).map(...);
for _, v := range x {
if !filter(v) {
continue
}
vv := apply(v, ...)
vm := map(vv, ...)
...
}Earlier quoted context omitted.
I disagree. IMO, there's much more cognitive load in parsing dense, "minified" code than there is in scanning code whose control flow mirrors its visual structure. Humans are very good at seeing visual structure (which is why we tend to indent, split code across lines, and other syntactically insignificant usage of whitespace). By convention in most mainstream programming languages, this visual structure mirrors code…
So, the thing specifically about ? in a language with Result is that you can read some code that uses it and not worry about what happens for Error cases if that's not currently your focus - the question marks aren't a "Look at me!" focus the way something like try-catch is. But if you are wondering about Error cases, they are there to see when you're looking for them because that ? while unobtrusive is something you…
Error handling is no less important than the happy-path.
Earlier quoted context omitted.
> I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. Right, go is for inexperienced programmers. > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language b…
> go is for inexperienced programmers. I am an extraordinarily experienced programmer, and I vastly prefer Go to Rust.
Earlier quoted context omitted.
The latter is a much stronger argument than the former (no idea why people get so worked up about character counts), but even then, "shit" is really strong considering how often one experiences exception traces when using an application written in Python or Java or some other exception-based language. Point being, we should probably evaluate error handling schemes based on results rather than ideology (even though I…
> no idea why people get so worked up about character counts Think of reading code as mining ore. If the ore is rich, you don't have to mine and process nearly as much of it to get the material you need. If the ore is poor, you have to invest extra effort to mine more ore to get the same amount of refined material. You might think Go is easy to read because lines are individually very easy to read, but Go code is so…
The expression
let x = f.a()?.b()?;
y, err := f.a()
if err != nil {
return fmt.Errorf("a: %w", err)
}
x, err := y.b()
if err != nil {
return fmt.Errorf("b: %w", err)
}
Earlier quoted context omitted.
> For example, Go error handling is shit What is bad about it?
Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations. For everything else, conditions+restarts are the correct answer, because errors-as-values restricts you to a single error-handling strategy and couples high-level code to low-level code as a result.
If a function call can fail, it should return an error, and that error should be managed by its caller. Any other approach means callstacks are unpredictable, which makes a program way way harder to model.
Earlier quoted context omitted.
> Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations Not really. It is acceptable for code whose maintainers value readability and simplicity over everything else. I totally agree that readability and simplicity are quite subjective and this is up to the maintainers. I don't really know what "conditions+restarts" is but a few a…
> It is acceptable for code whose maintainers value readability and simplicity over everything else. Errors-as-return values are less readable than conditions, not more - there's literally more visual noise on the screen. And if you want "simplicity", don't use a computer. Computers are intrinsically complex devices, users desire features with complex implementations, and our job as programmers is to manage complexit…
No.
When you make a function call, and that call can fail, then the happy-path and the sad-path are both things that you need to manage as a caller. Happy-path and sad-path are two equivalent states that both need to be accommodated by the program logic.
Error handling code is not "noise". It is equally important to success-path code.
Earlier quoted context omitted.
"Bubbling up" is common parlance for "exit this function early and return the error we got from our callee" (or "wrap the error we got from our callee and return that") In Go, this looks like thing, err := call() if err != nil { return nil, er } In Rust, this looks like let thing = call()?;
People keep telling me this is common nomenclature but I have never heard of it until today.
Earlier quoted context omitted.
If you need to use Vectors and Quaternions then Go isn't really for you either. The lack of any ability to do any operator overloading or writing arithmetic types along with the lack of parameteric polymorphism means you wind up doing stuff like Q.VectorMult(v) instead of just Q * v. Somewhere there's one of those "Go Koans" about how languages should allow programmers to easily express their intent, which I think th…
I kind of like making that a method since matrix products are not associative.
(Although it could really use a transpose operator as well and proper row and column vectors, but gamedevs are filthy savages)