An incomplete list of complaints about real code | Hacker News Reader

An incomplete list of complaints about real code

rachelbythebay.com

21 pointshacksilver6 comments

The author was intentionally careful not to "name names" but apart from occasional line noise it seems like Rust or modern C++ (in a pinch) are the sweet spots for minimising these complaints.

It makes total sense through a systems management lens.

But the things you care about when running software are different from those you have when writing the software. Good GC would be high on my list of "nice to have if we can afford some latency". And the concerns you have running code "at huge scale" are not the same as those you have at small scale...

Given their previous post about technology choices[0], I'd say modern C++ is probably ticking most of those boxes for the author.

[0]: http://rachelbythebay.com/w/2020/09/24/feedback/

“Modern C++” is very powerful, but also incredibly frustrating. Take std::variant/std::visit (sum types) for example.[0] Getting the value out is way more complicated than Rust. And if you mess up, expect an indecipherable multi-dozen line error message!

[0]: https://bitbashing.io/std-visit.html

I.e., don't design in such a way that you need visit. Most often, it's wankage. Design to eliminate wankage, and hire to eliminate wankers.

But that’s not the C++ way! /s

In reality, C++ is insanely complicated, and you’d be right about needing to avoid “wankage”, but sum types make sense sometimes. But the C++ committee refuses to do what I would consider sane and implement pattern matching. Instead, they gave us `std::visit` and all the confusion that goes along with it.

Pattern matching is under development. It's not an easy thing to get right. C++26 will probably have pattern matching, and then sum types will have better support. In the meantime, they might not always be the best solution.

Everyone complains about C++ complexity, and also about all the features they think should be added. But each new feature makes the language more complex.

The language is the wrong place to measure complexity.

Complexity people experience directly is in programs, instead. A well designed language or library feature makes programs simpler and more understandable. Obsolete language features fall out of use, and rarely occupy our thoughts. Mainly, when we find obsolete features in programs, that dates the code, and helps us know what to expect.

Reply on news.ycombinator.com