Hacker News Reader

Comment by LastTrain | Hacker News Reader

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?

View on HN

One 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.

Java 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

This is useful commercially, but also nice when building Minecraft mods for older versions of Minecraft.

This 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.

Reply on news.ycombinator.com