4 ms·

I don't think this is a nitpick, this is a valid point that actually plays even more into the concept of Rust's fearless concurrency. You're not avoiding the r

I don't think this is a nitpick, this is a valid point that actually plays even more into the concept of Rust's fearless concurrency. You're not avoiding the runtime overhead of a second loop but being able to operate on both streams in parallel would be a far more complicated concept in C/C++. This actually reminds me of that influential Rob Pike talk about writing a concurrent parser in Go.

quietbritishjim 6y ago
Ah, I wasn't sure whether to open that can of worms in my comment. The truth is I was sloppy using the word "parallel". The article describes interleaving the tasks but not actually multithreading them. Doing that in C++ would be just as easy as the article did it in Rust: you make a little iterator class (not necessarily STL iterator compliant, just that sort of idea) that hides the whole lexer behind an iterface that yields the next token each time. It wouldn't have the lifetime guarantees described in the article, but in this sort of context, if you're single threading, the object lifetimes are straightforward anyway. Maybe you could take advantage of Rust's lifetime guarantees to multithread things more easily than C++. That would potentially be a much more interesting article, if it turns out to be a lot easier than in C++.