Humans are social creatures. We’re not meant to live alone. The advise suggesting we should be able to seems to me like cope. I think you’re barking up the wrong tree.
Jews don’t have a right to an ethnostate. No one does. Jews have a right to live within any country in the world, but not run an apartheid government or commit genocide.
I think this concept is an exercise in fantasy. There’s simply no such thing as a free market. Why we single out subsidy as non free is arbitrary. What activities constitute legitimate free market behavior? There’s no actual logically sound distinction. The real distinction is “what we do is free market and what our opponents do is not”
My friend, what is so special about the government? If a company uses its massive profits in one area to crus competition by selling at a loss in another area, this is the free market, and when a government does it it is something else? I think you have not thought this through
We’re talking about China subsidizing goods that it sells in another country. This is bread and butter “free market” behavior. Literally every company in the world does this one way or another.
Anything is possible. Better to focus on what is likely. Did you stop using google over any of their outages? Most people didn't. These things matter, but people in software overstate them.
I agree that Either is more semantically correct. But is it more readable? Is it easier to manipulate? I don't think so. To have either, you need two big concepts:
1. Sum types. These can be really useful, and they _might_ improve Go, but they are undeniably a new complication and something users must now understand to work with Go code. This is not free. Is it the best use of developer minds to be paying rent to the Sum type concept? Or might dev teams be better off using that rent on some other domain specific problem?
2. Unwrapping. Now you have a container for your data, and you have to peel it apart to manipulate the data. This is a minor cut, but it adds up over time, and I think it leads to necessarily more convoluted code. `if err != nil` is the cost of separate err types, but visually its minor and Goland at least auto-collapses it so it interferes as little as possible with your code. I think matching on errs, or just propagating the error case, are both more complex for readers to parse. Furthermore, propagating a naked error loses crucial context (where in this function did we fail? what info from this function do I need to debug this?) that is dead simple to add in Go.
I think a sum typed has a semantic advantage, but it also has a cost, and I think you can make an argument its not worth the dough.
Sure, but I like Go a lot and am going to defend it, particularly from what I see as baseless or misinformed accusations (that quickly veer into resentment and ad hominem).
1. Extra indentation for both cases, instead of shoving only the error case aside.
2. How do you annotate the error with details of the current function? In go you can write `return fmt.Errorf("parsing point (id=%v): %w", id, err)` and easily add crucial context for devs to understand why an error occurred. This seems harder to do in rust.
Calling that a strict improvement is too black and white, and the point of my asking others to name good things about Go is to force a more nuanced conversation.
I understand why you’d expect me to be dismissive, but I appreciate your taking the time to write this. Errors are certainly verbose, but I personally find the benefit to debuggability and readability (where could this function possibly fail?) worth it. I think the considered and hand crafted error messages knock stack traces out of the park. I think the pain of unwrapping a Result type, and the pain of annotatingbit with function specific failure information, would be a step down from gos error handling.
Again, I understand why my comment came off as a trap, but trapping you is only one of my intentions! I’m also interested in understanding where you’re coming from, so thank you.
I’m happy to acknowledge real trade offs made by go. Error handling in go makes writing code harder. This thread is very hostile to go, so it makes sense that my comments express similar hostility.
A lot of the criticism of go is a little bit like a guy who hates New York pizza saying “New York pizza sucks, it’s only 1”. Chicago pizza has 4 more inches which has been state of the art for years”
Sure, it’s different, but that doesn’t mean it’s bad, and if your criticism only focuses on one detail and leaves out the whole picture, no kidding you produce a harsh judgement.
In the spirit of keeping this specific, and to demonstrate your understanding, I’d be curious how you’d answer these questions:
1. What is good about go’s file abstraction? What are the specific real world consequences (the article, which I was actually referencing in my comment, doesn’t deal with what happens in practice)?
2. What is the downside of increasing expressiveness? What is the downside of supporting sophisticated abstraction and type systems?