C++ Coroutines Do Not Spark Joy
probablydance.com
probablydance.com
After a lot of back and forward, the committee decided to pick the most proposal (i.e. the MS one) with the most complete implementation and potentially less ambitious. These are both good good features, but we ended up with a very complex, hard to use, design that requires unspecified compiler magic to remove all overhead.
Interestingly enough the committee went in the opposite direction for networking recently rejection the battle tested ASIO, again from chriskohlhoff, for a yet unproven design initially from Facebook, now Nvidia.
edit: personally I'm a huge fan of stackfull coroutines, but I could have lived with zero overhead stackless coroutines. The current design is IMHO the worst solution. Then again, sometimes it is better to ship something than argue forever.
They should have stayed away from ASIO. It looked like they were going to, for a while, and it looked like it was going to be better than boost's implementation. But here I find out that was never the case and the portions that needed filled in required compiler support.
But straight ASIO is pretty bad.
Edit: btw, I'm a huge fan of Eric work and he was my GsoC mentor back in '06. It is just sad that we got into an either-or situation and we couldn't get Net TS in the standard.
Chris proposal was "just" syntactic sugar over that. He went so far as producing a working implementation on a clang branch. The most important difference to what was eventually standardized is that the coroutine object is a non type erased value type (basically very similar to a lambda, and in fact an extension on top of it). The big issue is that it was very hard to use safely as the address of local variables could potentially change between invocations if the coroutine is copied around.
Facebook is very invested in coroutines, all major internal libraries at this point have a coroutine interface (in particular Thrift auto-generates coro client interfaces), and they have enjoyed wide adoption, way beyond the small cabal of C++ gurus.
Personally what sold me is cancellation handling. It really is magical.
Are your concerns about frame allocation? Is this something that the nanosecond-latency crowd particularly cares about? :)
My issue is stackless coroutines would be perfect for generators but the required allocation kind of kills it :(.
My experience with fibers is that they're stack overflow generators. Presumably you want lots of them running concurrently, so you'll need a small stack size, and now you have to be extremely careful about what code you run in them as it's very easy to run out of stack.
You can't rely on overcommit because if you actually end up touching the pages you're stuck with them.
> My issue is stackless coroutines would be perfect for generators but the required allocation kind of kills it :(.
That's true, though it depends on the granularity of the operations you want to run in your generators. Ranges+algorithms should cover most of the simple/small cases?
Having said that, I think that full coroutines can be no worse than stackless coroutines for stack usage. There are multiple options, including segmented stacks (which do have performance and ABI implications of course).
My preferred solution would be to have first class continuations and have the compiler convert them to stackless coroutines if the calling continuation never escapes the top level frame. In fact even yielding from inlined, non recursive functions would still allow the conversion to be performed while giving better ergonomics than the current implementation. The trick here is how to extend the language in such a way that this can be a guaranteed optimization instead of QoI. If this can be made to work, I think the same exact optimization could remove the frame allocation for stackless coroutines. Unfortunately I suspect this might require adding the equivalent of rust lifetimes to C++.
You can still avoid overflows even on a pure library implementation without compiler helps by switching to the main thread continuation (and its stack) for any stack consuming operation (or any operation that is known not to context switch). This can be extremely cheap, just an additional register swap over the normal function calling convention.
YMMV.
> You can still avoid overflows even on a pure library implementation without compiler helps by switching to the main thread continuation
Yes in fact that's what we had to do with fibers (see for example folly::runInMainContext()) but that means that all code that may be called from a fiber needs to be fiber-aware, which is not ideal.
The newcomers struggle so much to learn the language, and tbh I just say to them to learn the sane 5% of the language and ignore the rest. It's a monstrosity, extremely hard to bring up and generally not nice to read nor write.
I really wish a good, well-maintained, modern (as in, actually break stupid compatibility, just fuck it. It's 2021 for God sakes) C++ existed.
It is still suffering from that. If you want to manage memory yourself you can't use some parts of the standard library + you can't use a lot of the community packages since they assume there is a GC present.
So far it looks like the best alternative is Zig, but sadly it doesn't have some of the higher-level language features such as function overloading, compile-time interfaces (Rust traits) or macros. Jai seems to have most D features and more without the GC [0] but Zig is more likely win popular mindshare since it already is in the open + comes with a C/C++ compiler which is pretty cool.
[0] https://github.com/Jai-Community/Jai-Community-Library/wiki
The reason for the language not being available is that the designer (Jonathan Blow) doesn't want to release something half-baked to the world (because "there is already so much garbage software out in the world", or some line of reasoning similar to that). I don't agree with his reasoning, but I understand it TBH. He also has the reputation of taking too long to develop his games, but when they're finally released they're pretty good.
Anyway, it doesn't look like it'll be released to the public soon so like I said, Zig is the best alternative right now -- and it's gaining more and more users, so when Jai finally gets released, Zig might have already won.
- Zig doesn't have operator overloading while Jai does. Maybe a minor nitpick compared to the other ones, but this is a must-have for any math-heavy code, even crufty Orthodox C++ practicioners seem to use it.
- Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow.
- Jai's compile time evaluation is far more powerful - it can access the disk/internet and call any libraries. This is probably a horror show for any webdevs who like to do "npm install" without any thought, but in the case of gamedev where you have precise control over your dependencies this gives a much more higher degree of freedom. (For example, with this I imagine not only Jai code replacing all your build system scripts, but also asset management, packaging, localization, and publishing as well.) Jai's compile time evaluation also runs in a custom made bytecode-interpreter, which is probably going to be way faster than interpreting raw LLVM IR (which is what I think Zig's implementation is doing)
- Jai's support for switching allocators on the fly seems a bit less elegant than Zig's approach, but for actual usage I imagine it will be a lot ergonomic to use.
As you have said, you can't dismiss the community traction of Zig. But for me the most important thing will be: which language will actually ship a (reasonably sized) commercial game first. In that regard, as Jai's release will coincide with the Sokoban game that Blow's making it with, I think Jai will be the next language I try after C++ (well, if it releases though...)
I suppose you mean compile time when you say "faster". But LLVM also gives you many backend CPU (and even GPU) targets out of the box. Rolling your own backend probably means x86 and maybe ARM. Lots of work targeting new architectures that is saved by going with LLVM.
For actual deployment (release builds for various architectures), the LLVM compiler can be used for Jai.
Zig, by design, doesn't have overloading of any name, period (which also includes operators).
So is Zig. In fact Zig might be even more aggressive about this - they chose to aim for an in-place binary patching approach explicitly for the purpose of fast rebuilds and simplifying live-reloading.
¹ nor seriously coded in C++ in a long time, for that matter, so take this statement as an outsider impression
I think what people mean is that Rust violates their perception of what C 'is' - 'simple, bare-metal, low-abstraction'. Well I don't think C is any of these things and Rust's memory model (borrow-checker) is a much more explicit and precise representation of the actual (implicit, undocumented) invariants of your C program. In that sense it is 'simpler'.
Meanwhile Zig has a lot less perceived complexity, and most of it appears to be similar enough to the "C complexity" that C programmers are already familiar to not scare them off.
(Again, I'm just giving outsider impression of someone who just read a ton of blog posts and basic tutorials + standard library stuff without really coding in either language)
It is like handling butcher knifes without metal gloves, they think they are worthless until they repent not wearing them.
Yet. C++ wasn't as complex as C++ back when it was Rust's age. It wasn't even as complex as Rust. But if you pick a language for the next 20-30 years, you don't just care about where it is now, but also about where it is headed.
This is obviously easier coming from behind. You simply don't have to (and shouldn't) repeat other people's mistakes.
> It wasn't even as complex as Rust
I'm particularly dubious about this claim. Even counting from the genesis of C++ rather than standardisation, yet counting Rust as starting only in 2015, C++ after six years not only has multiple inheritance and overloading of everything, it also already has templates. That's a lot of complexity.
There's no such thing as "getting things right the first time," because what's right depends on external, mutable, factors. The best anyone can do -- and most successful languages achieve -- is being well adapted to the environment. But the environment changes. For example, Java's object model was well adapted to an environment where memory access and computation were of roughly similar speed, but hardware changed so that computation is now faster than memory access, so Java is now changing to adapt to the current environment. On the other hand, its bet that memory is cheaper than computation has so far proven relatively long-lasting. But there's no telling what needs new hardware architectures or new software requirements will bring tomorrow.
Both Java and C have adapted better, in my opinion, than C++, and it's not because of specific features, but because of their evolution ethos, which is different not only from C++'s but also from each other. My personal opinion is that C++ has tried for too long to be both high and low level, and that has shaped its particular evolution. I feel that Rust is repeating that same fundamental mistake, but, of course, others may disagree.
Take "explicit". In hindsight I suspect even many C++ proponents would agree that actually you don't want C++ conversion behaviour (when calling a function that takes a parameter of type X and you've provided a parameter of type Y, the C++ compiler will look for any way to construct an X that only needs a Y and then call that constructor rather than report that you've got the wrong type) by default. Perhaps C++ should have implicit conversion you can opt into, but it certainly should not have (as it does today) implicit conversion you must know about and opt out of to avoid blowing your feet off by mistake.
But I argue that it goes much further than such superficial mistakes. Multiple inheritance is a mistake. Personally I'm sold on the theory that all type inheritance is a mistake full stop (heritability should be a property only of interfaces), lots of people don't agree, but far fewer support the choice C++ made to embrace multiple inheritance of types. It's just so rarely even useful let alone the best option to solve a problem.
That depends what you mean by "things." Obviously, languages created in 2015 might fix mistakes made in 1985, and recognised as mistakes, in, say, 1995. But the things that a language needs to solve over its lifetime are mostly unknown when it's created. How the language handles the problems that are known when it's created is less interesting. If it doesn't do it well, it will never become popular. What's interesting is how it adapts when those problems change with time and new ones appear.
Plus if you're using C at a high level you ought to be using a static analyzer anyhow, that may not impose the exact same restrictions on you as Rust, but should be imposing enough discipline on you that using Rust doesn't seem so foreign.
On the other hand, if the thing you don't like about C++ is that it keeps changing you may be unsatisfied in Rust too because Rust has in some ways an even faster pace of changes. Rust as it was written in 2015 still compiles on a modern Rust compiler (with edition set to "2015" and modulo any security issues) but it is no longer idiomatic Rust.
This is precisely what the Rust edition are there to solve: your legacy code will work but the language will change with each edition to reflect the state of the art, and if needed, it will break backwards compatibility.
I'm not sure there are any security issues associated with using an older edition. I think when soundness holes and other things like that are fixed, they're usually fixed across all editions. Sometimes that's technically a backwards-incompatible change/fix, but Rust's back compat policy considers that acceptable if the breakage isn't widespread.
The changes since the 2015 edition have all been relatively minor in terms of idiomatic code I think. I mean sure, you can use the '?' operator instead doing a manual match and return, but most of the changes have just been making the compiler more permissive in terms of what it accepts.
The only new concept to be learnt would be async-await, and that should be familiar to most from other languages and only applies if you're doing IO.
fn twiddle(foozles: impl IntoIterator<Item=Foozle>)
But in 2015 you couldn't have written that. It works in the 2015 edition today, sure enough, but it would not have worked in any 2015 Rust compiler, and so it was not idiomatic Rust in 2015.
Instead in 2015 you'd have either chosen to specify what sort of container the Foozles live in, or, if you believe freedom to choose different containers is important to your users, you have to ask the caller to Box up an Iterator over their Foozles so you don't need to care what container they used.
so e.g.
fn twiddle(foozles: Vec<Foozle>) // Hope your foozles are in a Vector or else you'll need to write an adaptor function
or
fn twiddle(foozles: Box<Iterator<Item=Foozle>>) // Now we're incurring a heap allocation
fn twiddle<T: Foozle, IterT: IntoIterator<Item=T>>(foozles: IterT)
So sometimes you still want to use the "old" syntax in your public APIs, even when you could be using an impl trait
fn twiddle<I>(foozles: I)
where
I: Iterator<Item=Foozle>
Generics and trait bounds are in the language from the start.
So you can write this function like this:
fn twiddle<T: IntoIterator<Item = Foozle>>(foozles: T)
GADTs are useful for extremely generic code and are required if you want to write a general Monad trait. There is currently no way to write a trait which says return Self, but with a different generic argument. And not just Self, any associated type on a trait is a single type so you can't have a requirement for an associated type to be generic.
Finally, the procedural macro system is kind of a mess at the moment. Last time I checked, you really couldn't write a hygienic procedural macro (though I think this can be added later on without. A bigger limitation is that you don't really have any way to access type information in a procedural macro. Obviously type information is only available after parsing unless you make the macro system in Rust way more complicated, but it would be nice to have static type info for other modules. Having this information would allow you to do stuff like generating serialization code for some library that you don't control.
I thought I knew C++ well enough to get by. But in my current company, there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features. Basically, it seems they use all single features available.
And it seems some people love this mess.
I wanted to learn more low level programming when I was a C# dev, and coming from an OOP background, I chose C++ (also I had encountered c++ in school as a first language) . Man, was it humiliating asking questions even on stack overflow. Apparently everything is obvious and I'm an idiot.
In any case, I dropped C++ (not because of the obnoxious community but the language felt so poorly designed, coming from C#) and turned to C. Its been so far an amazing experience learning from C community. They are deeply insightful about computers and genuinely willing to help new engineers. Very experienced and very high calibre c engineers were helping me out without trying to show off how much smarter they are than the rest of the world despite being clearly far better and smarter than I am.
I turned away from the C++ unity towards the Rust community because I saw the same issue as you, and am very happy about that decision.
(I guess I'm old and misanthropic but I would not seek out answers by asking on the internet, but instead by reading one of the many excellent books on C++. It's not some obscure hobby where you need the collective wisdom of old hands.)
Now, I've been doing C++ for 20+ years, and the only real way to get help/mentorship in my experience is people you work with. There are too many ways to do any given thing in C++ and what you want is to follow the coding practices of the team.
Kind of proving the other persons point for them...
1. stackoverflow is a bad "community" for any field.
2. I described how I would approach learning C++, based on my personality. I didn't "direct" anyone to do anything. Especially since I phrased it as a literal parenthetical.
One thing i have noticed is that many people trying to learn C++ (or any other language for that matter) don't even do the basic homework (eg. read a book) before asking questions. They expect everything to be spoon-fed and to "easily" understand it all. Even a little effort is too much. They simply lack the commitment and persistence to learn anything non-trivial.
I don't mind using the latest features, there are some really nice things like iterators, compile time expressions and so on. I just don't want it to be hard to read or understand (like you said, using ALL the latest features).
So a good rule of thumb for me has been "if I give this to a newcomer, will he be able to infer what this is doing?". If yes, it's generally "safe" to use it.
I think I remember what the breaking point was for me. I had a custom serialization format (something YAML-like, because of course I had to implement my own custom format) and I wanted to pretty print it. I needed to implement some kind of indentation routine, you know, add a number of spaces at the start of a line depending on the current nesting level.
I wrote an indentation class that was fully generic. As in, the whole concept of indentation was abstracted away, I wasn't dealing with line buffers and characters, I had generic streams of objects and everything was templated and Boosted to the max. Must have taken about 20minutes to compile on the CPUs of that time. I was proud of my mad cpp skillz too.
And then the absurdity of it struck me. Over the next few years I found myself returning to the simplicity of C more and more (not that I would recommend C as a replacement for C++ in the general case, mind you).
Often when I read C++ discussions these days I think I detect the same kind of hubris I used to experience. Just writing ultra-complicated code for the sake of some perverted notion of purity and elegance.
So when you mix that mindset with the "and the kitchen sink too" ethos of the C++ language committee, you end up with the unmaintainable monstrosity that's modern C++.
But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated.
And then there is the question of what gives you joy? I find that for most coders, their primary motivation is not to solve a customer problem in the quickest, simplest and most efficient way, but to challenge themselves with riddles and learn new tech and follow fashion. This definitely varies by culture - Golang and Haskell are on opposite ends in that spectrum.
Overcoming delusion means to exit one's own mind and observe the real world. Looking at useful and well-made software, in which language is it implemented in? A Haskell fan will have no trouble talking for hours about how its concepts are superior. But he will not notice that there is barely any popular software written in Haskell out there, and he will not understand what that implies.
At some point I realized that the nice examples from the books never mapped to the real world as cleanly. Exceptions were pretty useful, local mutability made lots of things easier, and category theory has no place in calling JSON apis over http.
I think a great number of talented programmers never learn that lesson, and continue futzing about with theoretical purity for its own sake.
I think you're on to something there, except for the "job security" part. I've met very few people in tech who are concerned about losing their jobs, and fewer of them would make things much more complex---they didn't have the skills.
In fact, most of the majority I have known who produced complexity were optimizing for nerd status and resume building, but would quit rather than maintain their own complex code.
My view is that we mostly read code a lot more than write it and code is basically the low level fabric on with we build higher level abstractions like business logic (except for some ultra specialized cases like shaders or vector assembly). My problem is that any senior engineer shouldn't have to waste brain cycles figuring out the language antics when reading code because that takes you away from the reality you really want to get to (the business logic or the intent of code). for a reasonbly senor coder the language really should be out of teh pecture. these antics often end up wasting attention and sometime resources because likely somebody would use that code in a way its not intended and it will have a subtle failure like using extra resources etc
PS: apologies for misspells in above para, was hoping to make a point.
Then I started a company and hired people to work with me and it hit me just how much of an absolute waste of time it is to know that stuff. It doesn't translate or generalize well, most C++ is a special kind of complexity that is only relevant to C++, and then when you hire people you can actually assign a dollar cost to the complexity and that cost is simply not worth it.
I still use C++ at my company, but I now use a very simple and straight forward subset of it, basically along the lines of C with classes and namespaces. No more boost, no more elaborate SFINAE, no more writing things to be so generic and obtuse and avoiding parts of the language that are too abstract.
In that vein I also avoid all of the mess introduced by C++20. Concepts were a missed opportunity, modules are beyond useless, and the fact that C++20 has both coroutines and ranges just shows how the language is designed in a Frankenstein manner. A good solution for coroutines would make the use of ranges unnecessary, and a good solution for ranges would make coroutines unnecessary.
Instead C++20 provides half-assed implementations of both.
Less infatuation with the tool, more focus on shipping maintainable code the first time.
I feel your anecdotal example is not fair as you're trying to pass off problems created by your team with it's ill-advised approach to adopting a programming language's latest features as problems with said programing language.
For instance, I feel you could make precisely the same case with a Java or Python project if the project's coding guidelines forced the adoption of all the new bells and whistles. But that wouldn't mean the languages have a problem.
Meanwhile, the golden rule of C++ continues to be favouring the principle of least surprise and picking a language version (often C++11, and not C++14/17/20) and a subset of features to be enforced at the project's coding guidelines, and build your project around those.
Frankly, your anecdotal example sounds more like resume-driven development claiming yet another victim than a programming language being too unwielding.
That being said, C++ is an extremely complex language, so there's much more room for the code to become insanely complex than in more modern languages.
in my previous company I have seen this happen (to a less extent) as a way of marking territory since such speghetti code sans detailed documentation basically means nobody else will touch it.
And nobody is worried that the compiler implementations are not battle-tested and/or fully optimized yet? Because that alone would scare me off of using the newest features in production.
And for everyone who feels they have to incorporate the newest features of modern C++, don't. Avoid modern fetishism and make decisions based off things that have survived the Lindy effect.
With this setup I find C++ pretty easy to work in. And I've built a team of ~50 devs that were productive on the same multiplatform C++ codebase (+ all sorts of language bindings).
As a C++ programmer I would say this language is Ada 2012 (see https://pyjarrett.github.io/programming-with-ada/four-months...). It's hard to get people past the initial shock of the Pascal family syntax, but once you do, you'll find it ludicrously close feature-wise to the base C++ feature set that gets used day-to-day (RAII, templates, etc.) but with a Pascal skin. It also comes with built-in concurrency.
I have fantasies of doing a "new" programming language which is literally a lexical translation of Ada into curly-brace syntax and calling it Curla. I wonder if anyone would notice that it was just Ada!
case Foo:
when Bar => ...
}
What's so shocking about Pascal?
But sure, using the reserved words BEGIN and END at the bounds of a block of code break people's brains ;-)
https://www.youtube.com/watch?v=raB_289NxBk
"We got a lot of mileage in Swift, saying no to things"
and
"You're not going to get to a simpler language by adding features".
I've taken two comments (I don't feel that they're out of context), and they're 100% correct. As is your comment about learning the 5% part.
> I really wish a good, well-maintained, modern (as in, actually break stupid compatibility, just fuck it. It's 2021 for God sakes) C++ existed.
I often joke to my colleagues and say that C++42 will be equal to D today, or in fact D from 5 years ago.
https://www.quora.com/Which-features-overcomplicate-Swift-Wh...
I’ve started putting together https://cppbyexample.com as a way for newcomers to learn because pointing them to a reference or outdated examples isn’t helping anyone.
Yeah, that's totally true. But I would also say that a lot of it in my experience is people not even trying to keep up with the standards and barely even writing C++11 style code. I wouldn't expect to go into a Python shop (my other language) and work with people who hadn't tried to keep up with that language for 10 years but many C++ devs seem to have that attitude.
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.
For a day to day programmer, that sort of concern is (usually) overkill.
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.
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.
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 "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 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.
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 work in games development and the rate of adoption of new C++ features is incredibly slow. Only in the last couple of years it sort of became ok to use auto(although still frowned upon). Foreach loops are still out of the question though. I don't see the need for higher and higer and higher levels of abstraction in C++. If you need that then we just use C#.
The central point of this article is "c++ coroutines may allocate". Except Rust's, are there are a lot of languages where you can enforce that coroutines don't ? I'm confident that this is not the case for any JVM or .Net based-languages ; let's not even talk about Python or functional-ish languages.
For me for instance, as bad as C++ coroutines may be, doing the same thing in C# than what I'd do in C++ is literally not even on the radar ; we just set a much higher bar for what is "good" in C++ which leads to a lot of depreciating-tone articles but one must not loose sight of the whole picture ; almost no coroutine implementation in the world sparks joy when the same criterion than this article uses is applied.
For example, C# doesn't run on 16bit microcontrollers, and many things in the language make it unsuitable for this. If you added this as another of the design constraints on C# then it would be more complicated for desktop application devs, or server devs. C++ handles all of these cases, so is necessarily more complex.
IMO what C++ needs is compiler support for warnings when "old" bad practices are used, which would allow the language to remain flexible and backwards compatible, while still providing guidance for the future.
For real? What's the argument there? I've never seen anyone complain about range-for, so I'm curious what the perceived problem there is...
Or are iterator based loops also avoided in that codebase?
It annoyed me so much I implemented what I consider the sane/common interface: `cvisit(variant, [](Type1) {...}, [](Type2) {...}, etc)`.
Yes, I realize my usage might not match with everyone's, but from my own experience and code I've read, this covers almost every usage (visiting sum types).
heh, this was literally one of my first uses of C++ variants: that job needed a generic set of mathematical functions in a way that emulated a weaker type system (with automated conversions left and right), while preserving the original types as far as possible, and did meaningful conversions otherwise e.g. more-or-less
using value = variant<int, float, string, vector<float>>;
value clamp(value x, value a, value b);There are many other more obscure new C++ features, whose usefulness is doubtful.
Having to write again the type, when the type is already provided by an initialization value, does not provide any kind of useful redundancy.
The word "auto" is also redundant, but there is no way to eliminate it without breaking the traditional syntax.
"foreach" also provides a long-needed simplification. It makes no sense to waste time with writing iteration limits and also expressions with either pointers or indices for accessing the elements of a data aggregate, when all these are things that the compiler knows better.
When C (1974) introduced its more powerful "for" syntax, instead of the traditional "for" with arithmetic progressions, that was a partial mistake.
The C "for" allows 2 features that were not available with traditional "for", assigning to multiple loop variables (using the comma operator) and other loop variable updating operations besides addition/subtraction, e.g. indirect addressing through pointer links.
Nevertheless, these 2 features are needed infrequently, but the programmer is forced in 99% of the cases, when a simple "for" is needed, to write a lot of redundant information in comparison with the traditional "for" (e.g. "for i in 0 to 100 by 3 do" vs. "for (i = 0; i < 100; i += 3) {" ) (with traditional "for", the most frequent simpler loops can be written in a simplified way, e.g. "for i to 100 do", when the initial value is 0 and the increment is 1, while in the corresponding C "for" you can only replace "+= 3" by "++").
For the 2 special cases, a better syntax could be found, without altering the syntax for the common case. At around the time when C was developed, the concept of iterators was introduced in Alphard and CLU, which is a better solution than the extended syntax of the C "for".
Introducing "foreach" in C++ 2011, has corrected a mistake dating from C 1974, by providing a simple syntax for the simple common case, so that the complex syntax can be used only when really needed.
The correction is not total, because there still are many "for" loops that cannot be written with "foreach" but which C "for" is still an overkill, e.g. the loops that access multiple arrays.
Nevertheless, not using "foreach" nowadays would be a weird choice (notwithstanding the fringe cases with RHS functions returning references to temporaries, which were discussed on HN some time ago).
It's really easy to make a mistake and accidentally make a copy of a reference, or obfuscate any conversions...which, I can imagine in the game engine world being quite a massive footgun.
for(const thingy &x : myContainer)
What's so illegal about that??? Are you also not writing your own move constructors and assignment operators?
Again, there's nothing wrong about foreach loops in general. I'm just saying that in my industry and in the engines that we work with even the "basic" features of modern C++ are frowned upon for <reasons>.
> As the coroutines are, I don’t quite know what they’re for. They seem like they might be useful, but nobody seems excited by them.
It’s interesting that these two sentences were written next to each other.
I get the (outsider’s) impression that they were written using something like ASIO as the standard use case, which is indeed one of long-lived coroutines. I’m not sure anyone else participated who had a different application.
The second observation “nobody seems excited by them” is generally waved away by saying “get it into the standard so library writers can add sugar” (which implies that such sugar will make it into the c++26 or 29, if at all).
I’m generally pretty happy with the direction the committee has been moving in since C++17 or even 14. But I agree coroutines don’t seem to have quite made it.
[1] https://github.com/capnproto/capnproto/blob/master/kjdoc/tou...
Most of my projects, however, were things I would have been willing to develop in languages that would heap allocate constantly, so that heap allocations are happening here that I am poorly controlling isn't driving me insane (though I agree it sucks).
(The argument about competition is just strange to me, as that's just how generators as an abstraction--in any language--work... if you want to be able to have a generator yield to a separate generator the way you do that is by first developing a flatmap function that takes a generator of generators and yields its elements.)
Compile times are pretty bad though :) Especially with coroutines: at least clang (don't know other compilers) AFAIK works by copying the same function n times for each resumption point, and that's extremely slow.
yields its elements -> yields its element's elements
It began with a simple goal of adding classes to C. The STL, inline functions, "true constants" were all nice stuff. C++11 introduced nice stuff like "auto", constexpr. But now the new features are increasing the complexity so much that it is becoming harder to learn the language. Is so much complexity worth? How can someone new to programming ever hope to learn this monstrosity?
edit: also the lack of composability is relevant.
I wonder about the allocation elision. Return value optimization became mandatory, and some compilers can already elide calls to new/delete and malloc()/free() in normal code, so perhaps it will be possible to guarantee allocation elision in the future in the most used cases.
[0]: https://github.com/lewissbaker/cppcoro#recursive_generatort
But you last question can be answered in a couple of directions: 1. you don't HAVE to use C++, if there's another language easier, or better suited to your goals, use that. I think as long as C++ is the best choice for some domains it will stay relevant. 2. you don't HAVE to know/use all features of C++. If you're working solo just ignore the parts you want. If you're in a big team hopefully the codebase is such that you don't need to know everything about it to be productive. 3. Is adding features worth it? Well if you take 1 & 2 in to account, I think the downsides are capped a bit, and the upside is: more options. But of course whether you prefer many options with a lot of complexity, or a straightforward language is subjective.
So just in general, I do think it’s fair criticism of a language for offering crappy features, even if it is “optional” to use them. (Not arguing either way for coroutines specifically, as I’m not a c++ dev).
The irony is of course that they have stripped stuff out. I spent a fair amount of time going through an old code base in my last job stripping out std::unary_function and std::binary_function. Not saying that the replacement isn't better however.
I've been continuously employed as primarily a C++ developer since around 2001. The language was pretty bad back then, but it's been getting better and better since C++11. The vast majority of the new stuff is absolutely wonderful to use, a huge improvement in productivity and code readability.
It’s a combination of institutional knowledge, domain-specific libraries, and low-level, hpc capabilities that keep C++ being used.
(C++ for low-level stuff, python for the glue is a common paradigm in scientific computing)
All browsers you use are written in C++ (Firefox, Chrome...). Node.js is written in C++.
We live in that bizarre world, where on one side we have C, an antiquated and simplistic language and on the other C++ a monster of complexity that provides also basic modern stuff C will never have.
Rust has complexity of its own but it's more like a "philosophical" complexity rather than syntactic. A lot of C and C++ developers just don't like how Rust works.
Same with constexpr. People used to do all sorts of stupid math / string concatenation in "template metaprogramming" to get compile time execution. Now they write (mostly) normal functions in standard C++ that I can actually read. The language gets more complex sure, but the code I read and write gets simpler.
C++20 is larger than C++11, sure. But for most users, it's simpler too.
It will not fix all the pre-existing legacy code that people deal with on a daily basis. Languages are like infrastructure. People need to get it right on day one since it's exceedingly expensive to fix later on after people have already started to build on top of it.
My real complaint about C++ is the utterly insane ABI situation. Only C++ code dares to touch C++ code, no other language can interface with it without a C interface in between. The new standards forced even C++ compilers to break backwards compatibility with themselves due to requiring certain data structure performance characteristics. There is such a thing as C++ code that won't even work with other C++ code produced by the same compiler.
I couldn't imagine writing C++2003 any more.
It'd be like if every time Java is mentioned everyone just bashes how terrible JNI's API is. Yes, it is bad. It's frankly horrifying. But it's also basically 0% of where you spend your time when writing Java on the daily.
That's not to say C++ is rosey in practice, just the problems that actually get encountered on a modern code base almost never get mentioned here while all these esoteric edge cases that never come up in practice are beaten to death.
For example take C++ templates. In this thread they are slammed repeatedly. In practice you know what? They're fine. It's not that bad. Template metaprogramming is brain bending and hard, and I wouldn't suggest it. But basic templated classes or functions? No harder or more complex than the exact same thing in Java or C#. And in practice that's really all you do the overwhelming majority of the time.
Sure, that version was cryptographically insecure, but 95% of the use cases of shuffling have nothing to do with cryptography and don't need to be secured. This is not a case like PHP's `mysql_query` which has an easy replacement: now you must declare an `std::random_device` and `std::mt19937` and pass them to your functions.
This nearly made me fail a job interview in an embarrassing way.
[1] https://en.cppreference.com/w/cpp/algorithm/random_shuffle
Maybe it would be possible to make a s-expression language with sane syntax that transpiled to C++ code and let you do arbitrary compile-time AST macros. You wouldn't have to rely on Turing-complete template insanity or whatever half-baked feature the committee shat out last. In principle it wouldn't even be that difficult to make something like this, since it wouldn't have to be an actual lisp. Might be an interesting project
One thing which usually happens is that engineers get overwhelmed with 2 threading models: They might already have a hard time to understand how normal threading works, and coroutines add another dimension on top of that. That's a non-issue for the engineers working on the proposals and some of the affected libraries since they are domain experts, but the minority of implementors of an API server or users of a HTTP client are actually IO experts.
The second thing which usually happens is that a couple of ecosystems start to exist on top of the foundations which are incompatible with another. So you no longer write code in C++, Rust, Python, Java etc. You are writing code in asio, tokio, asyncio or netty. While most of these e.g. have some interoperability or can coexist with other async runtimes running on different threads it's also not something easy.
And last but not least every one of the implementations has another set of limitations that one or the other person will be unhappy about. Whether its additional heap allocations, mandatory synchronization, lazy vs immediate execution, cancellation behaviors, etc.
All in all coroutines seem good tools to make reaching performance goals in a way that's a bit more pleasant compared to what we had 10 years ago (callbacks), but they always seem to be a compromise.
I'm wondering whether at some point we will see an uptake on fixing the shortcomings of plain threads to avoid having to reach out for coroutines and a decline in those. But security challenges and mitigations make it continuously harder to decrease system call overhead.
IMO it's traditional threading that's hard to get your head around not async. Pre-emption makes things much more complex.
Also after moving to Rust, traditional threading lost a lot of its scariness. The type system is just so good at preventing the multithreading errors.
What C++ people need to realize is that they can't keep their cake and eat it too.
Stepanov has always seen the STL as a starting point, not a finished library.
replacing a std::type by a semi-equivalent non-std::one has never taken more than a few minutes with my IDE's find-and-replace, on up to MLOC-codebases.
Saves littering the codebase with std:: everywhere without having to do a blanket using namespace std;
Personally, I would expect very heavy justification (incl. profiling results showing orders of magnitude differences in total task performance) and a very strongly tested + well documented implementation for anyone sending me a PR with their own implementation of a container.
How is that useful? For "easy" optimization? Because that's not how you optimize code.
Not every C++ application needs to win microbenchmarks when using hash tables.
strawman and you know it.
I never had any performance issue using the STL to deliver projects under the customer acceptance criteria.
The other use case is generators and there the hard to remove allocation hurts a lot.
Also, of course you do not need them. You also do not need C++, just a needle and steady hand.
There have certainly been times where I was SMH, thinking "that could have been simpler" maybe that's the beginning of a new phase.
I too enjoy learning the new tools, their tradeoffs and how to best apply them to solve a given problem. But to someone who has not invested this effort (and might even be reading the syntax for the first time), they might as well be reading a completely different language. I believe that is the complexity that is talked about.
I used to work with a guy who would hate all the "new stuff" and then belittle and berate newbies for not understanding his "simpler" code full of void* and COM code. A bizarre tradeoff of not learning anything new himself for 20 years, and then demanding everyone else knew what he learned 30 years ago. Inflexible. He'd still be using his Amiga if he had his way, cursing every new OS and computer system.
The interesting thing about the newer C++ stuff is that it really does look like a new language - because it is.
For example, Facebook's Folly has been updated to use coroutines and is being widely adopted at FB:
https://github.com/facebook/folly/tree/main/folly/experiment...
More seriously, I've come to believe that most people shouldn't be writing multithreaded code. More specifically, if you ever find yourself instantiating a thread directly you've probably made a mistake. It's possible you're writing something sufficiently low-level or a library or framework that justifies that of course.
From using Hack, I've come to really appreciate the single-threaded cooperative multitasking programming model for client code [1]. It's not unique to Hack obviously.
Part of the power of C++ is the ability to allocate things on the stack or the heap. This is powerful but the complexity cost of this is so incredibly high that I honestly question if it's worth it.
It's unsurprising to me to see the complexity that comes with coroutines as a result of this.
[1]: https://docs.hhvm.com/hack/asynchronous-operations/introduct...
std::thread t([](){
std::cout << "thread function\n";
});
t.join();
I haven't used Structured Concurrency long enough to form an opinion whether that is the right level of abstraction or not.
If there's any overlap you have to have a lock-equivalent that ensures the desired section of code runs atomically (relative to others using the same pieces of state). Or you need some kind of transaction system that can retry a stateful change.
I am more thinking through "shared states" needs to be published after exiting a critical section [1], and other states are passed along from one critical section to another (either as copyable values, or immutable state objects). At least this is the easiest for me at the moment to reason about a piece of concurrency code.
[1] I am using critical section here to loosely describe a block of code needs to be executed together. It can be code between two yield points (in coroutine), a "task" object (in traditional task based scheduling), or section of code protected by a mutex.
At times I almost think there might be subset of C++ that sparks more joy - sometimes I try to program in it!
I'll agree there's some ugliness, but it's way nicer than trying to do something without compiler support. I looked into coroutine libraries previously, and I just gave up on them as being too much of a hack.
C++ language development is a classic case of what feature creep looks like for a software project that is on the path to self-harm.
I look at the colossal ancient Delphi codebase that my old employer had as a great example.
Or the Magento system in PHP as another example.
Or all the Objective C in the world that won't work on modern macos or iOS/iPadOS as another example.
Google folks have already removed the obstacle in that direction by adding userspace switching to the kernel in recent kernel releases. Just go all the way now, and release the kraken.
Last update I've seen on this is this article from June of this year: https://www.phoronix.com/scan.php?page=news_item&px=Google-F...
Imagine how excruciating it must have been to all the Google people on the C++ Standard committee to work on this stuff that comes nowhere close to what they've been using internally for years, and not be able to talk about it in any kind of detail.