It is of public knowledge (or, at least, for those that interact within communities related to software) that not a lot of companies use Rust; hell, not a lot of them even use Go which is a much more approachable language. No matter where you go or what industry you’re in, it’s more than likely that you’ve had to deal with an old Java system or some VBA application which has some of the most al dente spaghetti code you’ll ever see and that is fine in pretty much 90% of the cases for most companies; as the phrase we’ve always heard says: “If it’s not broken, why fix it?”. Being honest, yes, the phrase holds a lot of truth, but when old apps don’t meet the current business needs and become a fountain of frustration and curses on a Friday afternoon at 4pm because you just want to go home but can’t because “the godamn application doesn’t do what I need”, that’s when we have to start rethinking if it’s good or not to renew our tools.

The Obligatory Disclaimer (booo!)

Now, there are always, of course, cases where a company cannot afford to renew their tools: budget for the IT area may be extremely limited, manpower is not enough, they outsource their app and have no way/knowledge to manually change it, etc., all more than valid reasons! Of course you won’t expect a mom-n-pop shop to use latest payment system: over here most of them still use their trusty notebook and pen; it’s already a miracle if you see any using Excel. If you’ve ever attended a class about business management or have been in the industry long enough (if you’re fortunate, hopefully both), you’ll quickly notice how our customers (that is, society) will not give a single crap about which stack you’re using (unless they of course have knowledge of the area and want an specific project comissioned to their needs), they just want it to work and to solve their pain points. That’s just lovely, isn’t it? Working with your preferred stack, no strings attached, you just gotta deliver a product that’s not even necessarily nice to look at, but useful.

The Market Demands, the Market Gets

Software engineers are nowadays found with incredible ease (the market is that saturated, yes) and the surge of LLM assisted coding (whether you like or not) have made it so that there’s no excuse for innovation! Or, that’s what we are logically led to believe. Instead, we are seeing the exact opposite: what should’ve been a boom for the innovation space in the software ecosystem has been reduced to a group of people funding a startup dedicated solely to making an online call transcript app #92145 which is “powered by AI”, of course! And this is not just happening in the United States or Europe, it’s everywhere: app quality is going down the drain (looking at you, GitHub), all pages look and feel the same, stupid chatbots have replaced actual people behind support making the experience absolutely miserable for us consumers, so what’s going on? Now, I am not specifically blaming LLMs for this, but they have accelerated a trend that has been going on for years: rising stocks above all else. How does this affect the industry though? We, society as a whole, have accepted mediocrity as something valid as long as it works: we’ve not only seen it happen in the software we use (no matter how deep we are in the tehnical space) but even to other industries like food or manufacturing.

Now, does this directly translate to mediocrity = Java monolith? Hell no! But it’s precisely that conformism that gives these industrial-scale projects such a bad rep: what they needed in 2010 is not the same as in 2020; hell, what was needed till March of 2020 wasn’t the same as the rest of the year! When I mention conformism, I of course don’t mean it for a mom-n-pop shop or a small restaurant, I mean it for companies that can actually afford these sorts of rewrites. Having said that, like in the disclaimer, I understand that if your Java app from 2007 someway somehow still works today with your current workflow needs, then that’s awesome! Most likely though, something new is needed to keep the sanity of the workers (and our own) afloat: there is nothing more frustrating than having to work with a system that constantly breaks or that doesn’t do what you need to do (or both!). You’ll often hear managers saying stuff like “well we don’t want to break the flow of things” or “we can’t really deploy it because we need everything to work 24/7” like, habibi, the app itself already breaks the flow of things, what is there more to break?

Enter Rust

Now, I have ranted quite a bit about the current state of commercial applications and you’re likely thinking “what the hell does any of this have to do with Rust?”, which, fair, but here’s why in the title I mentioned Peru specifically and not other countries or the whole world: infrastructure costs. We’ve all seen stories of the dreaded AWS bill that costs more than student loans (just kidding, we all know nothing is more expensive than student loans) because of a certain misconfiguration in the backend that made it execute whatever in wanted, making a mockery of the developer team’s sanity.