There is a reason imperative programming is so common. It is more amenable to poorly designed, under specified, iterative development. Most real world software

There is a reason imperative programming is so common. It is more amenable to poorly designed, under specified, iterative development. Most real world software is in that category naturally. If you're meticulously designing and engineering it really well from the start, sure functional languages represent it well without leaving much room for misinterpretation and thus bugs. But no one does that. Marginal cost of adding a feature has to be proportional to the revenue made by that feature. Then In Java or go you just add a ugly special case to appease the large customer and ignore the small ones' emails. Bugs getting shunted around instead of truly fixed at the root is also totally OK as long as they are not in the major revenue/cost centers of the product. No one has time to replace these piles of hacks and eventually you would have given up most of your languages benefits and your types now mean nothing there is probably a hundred flags making it a union effectively. Rust is one language though where hacking around goes a long way without breaking too many of the guarantees, although it's not perfect, from my experience at a company where services spanned java go rust and ruby.