4 ms·
I always kind of scratch my head at this kind of language extension. In my world there are legacy projects and new projects. Why would I want introduce this in
by LastTrain 3y ago
I always kind of scratch my head at this kind of language extension. In my world there are legacy projects and new projects. Why would I want introduce this into a legacy codebase? If it’s a new project where async language features are important, why wouldn’t I use a language better suited for that?
- opticfluorine 3y agoOne reason is new applications in legacy enterprises that are slow at adopting newer/better languages for a variety of reasons. I used to work as an embedded SWE for a Fortune 500 that made heavy use of C++ and was very resistant to Rust/Zig/others, but was much more willing to adopt newer versions of C++ for new projects. Although I would have preferred to work in Rust, having features like these would have been great in that environment.
- bombcar 3y agoJava has things like Jabel that let you use modern Java syntax and compile down to Java 8 for compatibility reasons. https://github.com/bsideup/jabel https://github.com/bsideup/jabel This is useful commercially, but also nice when building Minecraft mods for older versions of Minecraft.
- gpderetta 3y agoThis is not a language extension, it is a pure library feature. C++ has had async/await for a while, so it is perfectly suited for that; sender/receivers build on top of that functionality. In any case, Eric Niebler now works at NVidia, which has expressed an interest on Senders/Receivers as they are not just for networking, but a general mechanism for composition of async operations. I still have my concerns, as I think the heavily templating will come at a cost of clarity, but I haven't tried them on a large application yet.