hesus_ruiz

The value prop of Go in not on writing, but in reading and comprehension by people different from the autor(s). For systems expected to last some years, this translates in reduced total cost of maintenance over the life of the system (in my experience typically 80% or more of the total cost) and facilitating traspassing maintenance to diferent people than the authors. In use cases where Go has "good enough" performance, for backend systems with business logic and small amount of "bare metal" programming, I recommend Go to teams instead of Rust. When extreme performance and reduced memory footprint is more important than the other properties, Rust is better than Go.

Reading the article I got the same conclusion as every time I approach sum types: they are ONLY useful for addressing malformed JSON structs of hacking BAD data structure/logic design, at least for most business applications (for system-level programs my reasoning is different).

The example JSON in the article, even if it may be common, is broken and I would not accept such design, because an action on an object must require the action AND the object.

For many year, I have advised companies developing business applications to avoid programming constructs (like sum types) which are very far from what a business man would understand (think of a business form in paper for the first example in the article). And the results are good, making the business logic in the program as similar as possible to the business logic in terms of business people.

The author must have specified in the title: "Blocking code IN RUST is a leaky abstraction".

I am so happy to be using Go for most programs!

It has one of the best concurrency implementations that I have ever seen (Erlang permitting ...). And for most of my programs, the garbage collection is not a problem. It's the opposite: simplifies programming incredibly.

No blocking versus async problems. No libraries for async are needed. Just concurrency (which has its own problems, but this is another story ...).