You should use tools that are appropriate to what you intend to achieve. If you want to make a 3D game then Unreal, Unity, or Godot are appropriate choices. If you want to make a 2D game then something like MonoGame might make more sense than Unreal. You don't need highly refined netcode if your game never needs to exchange data in realtime.
Heck, I've seen someone build a visual novel-type game with WinForms. That was actually a sensible choice for the game's presentation and interaction needs.
Of course if you want to become a game dev at a studio then you should be competent with whatever the studio uses (or something comparable so you can pivot to their stack). If you only want to make your hobby project and maybe publish it later it doesn't matter if your engine is Unreal, MonoGame, RPG Maker 2000, or vanilla JS/DOM.
It's an implementation of an old recommendation to never have more than 80 characters per line, ostensibly to limit horizontal eye movement but mostly stemming from legacy 80-character terminals and punch cards.
The value of that recommendation is rather dubious considering today's high-resolution displays that allow for smaller font sizes. 80 readable characters at 768p are not the same as 80 readable characters at 4K.
Work with OpenDocument to get the necessary features into the next version of ODF while keeping national bodies informed about the status of that effort. In the meanwhile, allow Office to save (with reduced functionality) to ODF in order to fulfill the requirements of existing standards-oriented procurement processes. (Fun fact: They did the latter pretty quickly.)
Here's what they shouldn't have done: Undermine ISO's credibility by ramming a hastily-constructed, not-yet-implemented spec through a fast-track process intended for mature specs by stuffing national bodies. I see no reason to place Microsoft's short term profits over the integrity of international standards bodies, nor do I see one to excuse Microsoft for doing so.
In my experience, fintech companies (including ones that either belong to or own a bank) follow one of two playbooks:
- Issue high-powered laptops that the developers work on directly, then install so many security suites that Visual Studio takes three minutes to launch. The tech stack is too crusty and convoluted to move to anything else like developer VMs without major breakage.
- Rely 100% on Entra ID to protect a tech stack that's either 100% Azure or 99% Azure with the remaining 1% being Citrix. You can dial in with anything that can run a Citrix client or a browser modern enough to run the AVD web client. If they could somehow move the client hardware to the Azure cloud, they would.
I don't really associate fintech with a modern, well-implemented tech stack. Well, I suppose moving everything to the cloud is modern but that doesn't mean it's particularly well done.
But that's a tiny model; it's the smallest version of Llama 3.1. The commercially marketed models are way bigger - e.g. GPT-4 has been estimated to use about 1.76 trillion parameters, 220 times more than the Llama build you mentioned. Their resource and performance requirements are vastly different.
You're essentially arguing that shipping naval diesel aggregates must be trivial because you can fit a dozen moped motors on the bed of your pickup truck just fine.
Heck, I've seen someone build a visual novel-type game with WinForms. That was actually a sensible choice for the game's presentation and interaction needs.
Of course if you want to become a game dev at a studio then you should be competent with whatever the studio uses (or something comparable so you can pivot to their stack). If you only want to make your hobby project and maybe publish it later it doesn't matter if your engine is Unreal, MonoGame, RPG Maker 2000, or vanilla JS/DOM.