If anyone reading this feels like trying something new, I encourage you to learn functional programming instead of finding creative-but-safe ways to use goto statements.
I think this opinion is a bit too coarse to describe current trends.
Certainly, current best practices recommend things like std::ranges, Streams, or LINQ instead of old-school for-i (or even for-each) loops, with good reason: the pipeline and map-reduce paradigms are very useful to simplify and shorten code especially when the same operation is applied throughout a data structure. This sort of operation also tends to be embarrassingly parallel, easily lending itself to performance boosts with SIMD and vectorisation.
However, pure, stateless functional programming is useful only in limited contexts, and implementations tend to rely on either a GC runtime, or resorting to copying and overwriting data structures to maintain correctness and safety at the (sometimes very large) expense of performance and efficiency.
Purely stateless and functional programming is extremely hard to use in overwhelmingly stateful (read: video games) applications without things slowing down to unusable levels. Update an ECS tag? Write the entire state (which can be megabytes large) all over again—no in-place updates, after all.
I feel most (non-functional) programming languages are adopting FP paradigms, but will maintain their imperative core by replacing old, leaky, and error-prone abstractions with data-flow paradigms (like the for-i -> map-reduce I mentioned above).
I think functional programming has it's advantages and it's worth learning. But no, imperative programming is still the most popular will remain so for some time.
IMO functional programming is just a special kind of imperative programming. I think real distinction is between "imperative/functional", where you describe how to do thing, and "declarative" where you don't care about the hows, but you specify what is the end result you want to see. For example: html (declarative) "I WANT A RECTANGLE AT THIS POSITION AND SIZE": <div style="top, left, height, width">, while imperative, you exactly tell the how, like <for i> then <for j> draw a pixel at that position i,j. Making drawing a box as functional does not make too much sense, because that is a task, which does not benefit from the functional paradigm, but it does helps a lot with cardinality and null checking problems when dealing with other kind of problems.
I think it is already changing into this. Basically every single framework is one kind of declarative wrapper over an imperative language, or you can say every single function library makes the way how you work a little bit more declarative (like in the box drawing demo, you can just use function to write a box. I think in 20-30 years, in a very twisted way programming will be completely declarative by you telling an AI to write a code, first at a very low level of abstraction, but in time more and more complex ways. We'll see
I wrote my parser by iterating character by character (foreach) and when reaching those states that need reprocessing I found it nicer to jump to a goto label at the start of the foreach, after the state variable was updated.
If anyone is aware of a purely functional HTML5 compliant parser let me know, as I'd love to steal some ideas.
[1] https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.ht... ctrl-f reconsume
And as I've said, for HTML5 compliance you need to also parse JavaScript, see second sentence here https://dev.w3.org/html5/spec-LC/parsing.html#overview-of-th...
A good first smoke-test for HTML5 supporting parsers is the following html fragment
<input disabled>
Well, no. Rational world use what makes sense for particular situation. Not silver bullet du jour that suddenly solves everyone's problem (not).