It's bad practice, though unfortunately extremely common, to return unannotated errors like this. I can't think of the last time I've used this stanza. The proper form is, at a minimum,
and so on. The point is you have in that stanza the space to program with the error, same as any other value in the function. The... semantic equivalence? which the idiom reinforces is actually extremely good! Error handling isn't any less important than happy path code, and, IMO, language features like `?` suggest that it is.
> It's incomprehensible to me that...
It is not immediately clear that the first example is incrementing every even number. To get there, we have to parse the method names, recall and parse the special syntax rules for those methods, and, if we're being diligent, reflect on the ownership requirements and allocation effects w.r.t. their parameters, to make sure we're not doing anything with unintended side effects.
We're doing basically the same work in the second example, minus the ownership stuff. We're using more characters to do it, but that's not a priori worse. Parsing `res = append(res, v+1)` does not take more time than `map(|a| a + 1)`. Using curly brackets and newlines to demarcate transformation steps instead of monads is not more prone to bugs. It's the same stuff, expressed differently, and, IMO, more coherently: code written in the imperative style is generally easier to understand than functional. (I hope that isn't controversial.)
> There's no argument for the go loop being "better" than the Rust equivalent that doesn't also argue that the C version with the additional hassle of bounds-checking and manual incrementing is better still.
> Even better, if there’s an error, there is no non-error return value. You can’t accidentally use the zero-valued return half of a tuple (as you can in golang) because it simply isn’t there.
That is better! But it's not as better as I think you think it is. The conventions are adequate, here.
> Is the important part of error handling having some copy-pasted stanza repeated everywhere? Or is it enforcing that errors are always handled and semantically-undefined return values are never accidentally passed along in the event of an error?
Neither, really: it's about having the error code path visually equivalent to the non-error code path.
> No, it simply is not. `?` early-aborts the function and returns the result straight away if it’s an error, and unwraps the interior value if not. There is no plausible way for someone to mispredict this behavior, and if there was, it would be no different from golang, since the two constructs are semantically virtually identical. One is simply shorter than the other.
I don't want early abort. Don't know how else to say it. If I have 5 operations, each of which can fail, I want them to be 5 visually distinct stanzas in my source, and I want to be able to manipulate the errors from each independently.
> Ease of understandability is almost hands-down the most important metric given the ratio of frequency to code being read versus written. And to be completely blunt, it is flatly ridiculous that wrapping every line in nearly-identical error handling code somehow doesn’t impair comprehension. The argument is the same for abstractions like `map`, `select`, `reduce` et al. Intent and behavior of code can be understood at a glance when you remove the minutia of looping, bounds-checking, and indexing
I'm sorry, but I just don't agree. You call looping, bounds-checking, index, etc. minutia, but I don't see it that way.
I think the core of it is the belief that error handling is no less important than "happy path" code. In some domains, this isn't true. In mine, distributed systems, it is. So I don't want to relegate errors to some ghetto, I want them to be front and center, equal to everything else.
Another small part is probably how you think about the error values themselves. I almost never want to pass an error to my caller exactly as I receive it, I almost always want to do something to it first, most often decorating it with relevant context and metadata where I receive it. Sometimes, obscuring it, if I don't want to leak implementation details.
But ultimately it's about explicitness, obviousness. `?` is easy to miss, and permits method chaining, the outcome of which is incredibly easy to mispredict. And in imperative code, which is the supermajority of all code, `?` gives no meaningful increase in speed-of-reading -- which is a bogus metric, anyway. So for me, strongly net negative.
I totally agree, the current design language of almost every electric scooter makes the rider look like a total goober.
There seems to me to be a clear gap in the market for a scooter that... looks good. One that elevates the rider as little as possible, 2-3cm seems ideal. One with a front pole that lets the rider's arms stay mostly extended downward, rather than the current "water-skiing" posture. And one with significantly larger wheels, to handle anything other than perfect asphalt.
> You see yourself as some benevolent being moving humanity forward but reject any criticism of the costs of your actions.
I reject specifically your criticism, the criticism of cynics. I (obviously) don't agree with your characterization of which policies are "failed policies that end up costing others" or "how the world operates". Humans are of nature but also possess the ethical and rational systems to rise above it. We're not bound by our natural impulses; on the contrary, our gifts oblige us to be better than them.
Bluntly, I have no interest in living in a tribe with my Dunbar's number of tribespeople, organizing my thoughts and our policies under some presupposed limits of ambition. My ambition is boundless. So I say again, if you want to close ranks and subvert broad collective action and live in fear (or as you would say, some kind of steely-eyed realism) go dig a hole and do it well away from me. I've no interest in that moribund nihilism.
> Yet around the world this solution has largely failed
That's a cynic's worldview and it's one that I totally reject. Take your pessimism to a hole in the ground and wither yourself away there. Let those of us invested in the progress and future of humanity get on with our work.
> My point was that 20 years ago, there are a hell of a lot of people that would have made that argument.
I understand that's your point. And policy reflected that majority opinion back then. But, it was wrong, and we fixed it. That's fine. That's how things should work.
> Your proposed policy - which as far as I can tell simplifies to "ban advocating for things that a supermajority of the population finds distasteful"
I'm making no policy proposals. I'm saying society is justified in making moral decisions via policy, and in many cases is ethically obligated to do so.
I'm saying that a blanket position of moral agnosticism by government (which is, as far as I can tell, what you're suggesting) is naïve in the best case, and actually actively unethical in the worst case, when that position prevents a society from protecting itself from disease.
We still have courts even though there is the possibility of convicting the innocent, a society without a justice system is unworkable. In the same way, we still have the right and responsibility to make policy on moral and ethical grounds even though we might choose incorrectly, a society without that ability is unworkable.
> Should we also not be obliged to suffer ... gay rights advocates?
If you want to make a case that gay rights advocates make the world unambiguously worse, be my guest. At a societal scale, you will fail, because there is a clear and categorical difference between that example and mine.
It's fine that not everyone feels that way. The people who think gay rights advocates make the world worse are wrong, and society has the right to judge them that way.
Just because you can swap the nouns in a formulation of a policy and turn it from good to bad (or bad to good) doesn't mean that policy is wrong, or bad, or shouldn't be used. Social policy don't need to be content-agnostic to be useful. We can apply a policy against nouns that, in outcome, make the world better; and refuse to apply the same policy against nouns that, in outcome, make the world worse. We're gonna get those determinations wrong sometimes, and that's inevitable and fine, we can just course-correct and carry on in good faith.
I’m going to turn it around on you: how can we have a just society if women legitimately fear for their safety when they go to certain places? We’re not obliged to suffer white nationalists carrying tiki torches down the national mall chanting “Blood and thunder” and making the world unambiguously worse because we need to know their position exists. Sunlight is not always the best disinfectant.
> No one should be able to dictate what the proper "just and ethical outcomes" should be
Not only is every human _able_ to dictate what "just and ethical outcomes" are, we're _obliged_ to, if we intend to form civil society.
> Is today's morality the end of all things?
No, of course not. Everyone is obliged to continuously engage in the conversation, to push the course of all society away from suffering and toward justice.
> It can be an end itself if you find that any limits are prone enough to corruption to not be tolerated.
I understand that some people see things that way. And I'm saying that it's an insufficient, naïve, and (in our zeitgeist) actually unethical position.
It's bad practice, though unfortunately extremely common, to return unannotated errors like this. I can't think of the last time I've used this stanza. The proper form is, at a minimum,
Or, if there's additional, caller-actionable information about the error you want to provide,
and so on. The point is you have in that stanza the space to program with the error, same as any other value in the function. The... semantic equivalence? which the idiom reinforces is actually extremely good! Error handling isn't any less important than happy path code, and, IMO, language features like `?` suggest that it is.
> It's incomprehensible to me that...
It is not immediately clear that the first example is incrementing every even number. To get there, we have to parse the method names, recall and parse the special syntax rules for those methods, and, if we're being diligent, reflect on the ownership requirements and allocation effects w.r.t. their parameters, to make sure we're not doing anything with unintended side effects.
We're doing basically the same work in the second example, minus the ownership stuff. We're using more characters to do it, but that's not a priori worse. Parsing `res = append(res, v+1)` does not take more time than `map(|a| a + 1)`. Using curly brackets and newlines to demarcate transformation steps instead of monads is not more prone to bugs. It's the same stuff, expressed differently, and, IMO, more coherently: code written in the imperative style is generally easier to understand than functional. (I hope that isn't controversial.)
> There's no argument for the go loop being "better" than the Rust equivalent that doesn't also argue that the C version with the additional hassle of bounds-checking and manual incrementing is better still.
Reducto ad absurdum.