gthrowaway52

There is a lot of confirmation bias in this post. I will leave it at that.

Maybe I misinterpreted you. I don't disagree that checked exceptions and errors are ~the same thing.

> Go programmers, in 99.9% of cases, do manually what exceptions do automatically

Our experience working with Go must be very different.

Grepping for "err := " and looking at the first 10 results in my team's codebase.

  * 4 cases where the error is just returned
  * 1 case where the error is returned only if it matches a certain type (otherwise logged)
  * 1 case where the error is logged as a warning.
  * 1 case where the error is logged, some metric is incremented, and then execution continues as usual. (a fail-open authentication check)
  * 1 case where the error is returned as different error type.
  * 1 case where the error is returned, but only after accessing the result (this is a strange design / antipattern), and annotating it with a human-readable explanation.
  * 1 case where the error is treated as a boolean condition, and is not returned. (the error condition is "does not exist").

So in this sample it matches the "automatic behavior" in only about half the cases. In other cases, substituting the existing behavior with exception's automatic behavior would cause severe bugs.

I'm talking about unchecked exceptions. It's not about what is possible it's about what patterns a language encourages. It feels like we've lost the thread of discussion.

  - You say there is no difference between unchecked exceptions and Go's errors
  - I say yes there is since Go forces users to handle errors explicitly
  - You say that's not technically true in all cases.

OK. Yes. I should have said "nudges users" instead of force. It's a shortcoming of the language. It is still really hard for me to see unchecked exceptions and value-based error handling as the same thing. One of them encourages doing nothing and hoping that bubbling up is the right answer. Very often, especially in a multi-threaded context, it is not.

In Go the programmer is forced to make a decision on what to do with the error. Common patterns include (A) return an annotated error, (B) log it and continue, (C) retry, (D) aggregate the errors in some way. If you believe the only way to handle an error is (A), then Go's design makes no sense.

Well, yes, the menial parts of review can and should be automated. Big tech cos are leading the industry, and ML does find its way in there (with mixed success).

But at its core, code review is putting two heads together to write some code instead of one. In that sense you can think of the code review problem as the "automating away all of programming" problem.

> Just take a step back and think about what you're saying: that a bitcoin transaction would cost £3.40 in the UK

I hope I'm not misinterpreting your point, but bitcoin transactions cost even more than that.

https://ycharts.com/indicators/bitcoin_average_transaction_f...

Users have to bid for space on the blockchain to store transactions. Early on the space was cheap and miners got their profits from the # of bitcoins they mined. As that dries up the incentive to mine shifts toward transaction fees.

The electricity costs right now are unclear to users because of indirection. Mining dilutes the value of bitcoins each user holds but they do not see a loss in their wallet. I wonder if once confronted with even greater transaction fees over time whether users will be willing to continue to pay up to use it. One has to cross their fingers that the demand stays high enough to sustain enough mining to prevent the from being taken over with 51% attack.

Ignoring the article since it has almost no information in it.

I don't view the company is overall evil. I view it as a boring megacorp. One that makes news cycles because of internal activism.

The smaller companies I've worked at were more evil in terms of bad mismanagement, sexism, and misleading marketing. You probably haven't heard of them and no one spoke out against it.

I am curious what jobs other software devs have where they feel they are transforming the world into a better place. I've never felt that at work, and work is not where I find purpose