Hacker News Reader

Comment by banachtarski | Hacker News Reader

Coroutines let you control where allocations go though? Just override operator new/delete on your promise types. Honestly the feature has been amazing and has cleaned up my code a ton. It’s not for average users. It’s for library writers who then build abstractions on it to make async code easier to write for others. Exposing the coroutine frame as a non opaque structure is simply not practical. Not a super well-informed article IMO.

View on HN

> It’s not for average users. It’s for library writers

Justifying the complexity of an interface by appeal to caste system is pretty poor, IMO.

A very common methodology for solving big problems is to break them down into smaller problems, solve each one in turn, and compose them together. In other words, we use library-oriented programming. A productive feature in a programming language makes it easy to both create the library elements of the solution and to compose them together.

There are tons of facilities in the language intended for library authors and abstractions that are absolutely intended to be used out of the box. This is just how things are, features are provided at various levels of abstractions. I know HN loves to collectively hate on C++ but “caste system?” Lol

Yeah, it's part of the charm of C++. The is almost horrifyingly modifiable. As a library author, that gives a lot of control over the functionalities of the abstractions you expose.

For a day to day programmer, that sort of concern is (usually) overkill.

I think "caste system" is the perfect word for it. I don't think it is a bad thing though, I am fine with having such castes in c++. First time I saw coroutines of c++ I was definitely like "yep, this is for library writers". I am not excited about it, but I am excited about libraries that will use it.

It is similar how templated code that basically becomes "magic" for an average programmer like me. I can't wrap my head around such complex templated libraries either but the simplicity of using such libraries are sure welcomed by me. I think it is perfectly have some language features for more advanced users.

Hey, at least they are adding concepts. Maybe I will move up to another caste and will be able to write more complex templated code now.

> Justifying the complexity of an interface by appeal to caste system is pretty poor, IMO.

Ahhh, I mean, isn't that a decent-sized chunk of template-based code as well? I would hazard a guess that even for a "simple" one like std::vector<foo>, there are way more C++ developers who can use std::vector than who could implement a templated vector from scratch.

I, myself, fall kind of in the zone between. I'm not a template guru, but I work on the foundational/library-type code on my team and have to do my absolute best to make sure that the stuff I build for everyone is usable without needing to know the minutia about how all that stuff works.

Yes, and that's why templates are also often criticised as a poor design.

I think many C++ devs haven't read Stroustrup's book. The intro to C++ chapter covers most of what they need to know and then the rest of the book goes into beautiful detail with examples.

Most of the C++ developers I worked with were C++ developers in name only and wrote appalling code. I was one of these developers until reading Stroustrup's book and doing my own side projects to improve skills.

The difference is in the capabilities of what a library can do. C++ goes through a lot of effort to ensure any library has all the same building blocks as the standard library. Almost no other language does this. Instead, they just grant the standard library magic powers that they don't trust you with or just refuse to provide.

The "caste system" as a result exists in all languages. Just the vast majority prevent you from ever being a duke much less a king. C++ doesn't stop you. Whether or not this is valuable to you is then personal preference, but it's not complexity for the fun of it, either.

I think the fundamental flaw of C++ is the bifurcation of its target users into elite (i.e. library) programmers and "average" programmers. It makes the C++ standard library incomprehensible for normal users. The C++ committee members are composed of elite programmers, of course, so they keep adding features which are inscrutable to most users, and the complexity of the language spirals out of control.

I have a soft spot in my heart for C++. I have used it on and off for about 30 years, 8-9 of those years professionally. But the complexity of the language has increased so much that I am actually looking forward to not writing it anymore.

I wonder if Rust is any different. I wouldn't know.

Rust has a similar bifurcation. Most "regular users" of rust will not write macros, for example. Although my impression is that the divide is not as big as C++'s

I don't know that I would consider writing macros a sign of language expertise. I work on a large, intricate Rust project and macro stuff, while it does come up occasionally, is not what I would see as the "elite" bit of writing Rust. The best Rust folks I have seen understand Rust's type system, how it relates to the memory model and how those relate to the underlying machine.

I feared macros initially, but when I tried I was actually surprised by how easy they were. Way easier than Scala 2.x macros.

Rust has two macro systems. First it has declarative "by example" macros which I wouldn't give to an absolute beginner but they're very safe and give a flavour of meta-programming. A programmer with a good general knowledge of Rust, and a nagging feeling that there must be a better way to make these several almost-identical-but-not-quite new types they're working on can learn how to write "by example" macros and while learning probably won't set anything on fire. Rust even provides, out of the box, an easy way to see what the result was of your macro substitution.

Second, modern Rust has stable procedural macros. The procedural macros have essentially unlimited power, since they literally run inside the compiler processing the tokens of the program. Still, two kinds of proc macro, derive macros and attribute macros are fairly tame and, with due caution, merely competent programmers can experiment for themselves. It's really only the function-like proc macro that makes unlimited chaos likely and wants an expert. Stuff like whichever_compiles! (a macro which takes a series of code blocks and your program has the first one that compiled successfully...) is in this last category and is clearly toxic. Anybody who could write such things hopefully knows enough to do so only as an elaborate joke.

I regularly read source code of the Rust standard library. With C++ I don't even bother, it's futile.

Reply on news.ycombinator.com