I skipped using aider, but I heard good things. I needed to work with large, complex repos, not vibe codebases. And agents require always top-notch models that are expensive and can't run locally well. So when Codex came out, it skipped to that.
But mct leverages the weak models well, do things not possible otherwise. And it does even better with stronger models. Rewards stronger models, but doesn't punish smaller models.
So basically, you can use save money and do more using mct + codex. But I hear aider is terminal tool so maybe try and mct + aider?
Not racist but offensive indeed. It's like relating school shootings to white people. A white child sitting in Norway might not relate and may find it offensive and insulting.
India is a country, not a color of person. It's more like relating school shootings to the US, where an American child sitting in the US would definitely relate and find it accurate.
I feel, What's more harder are the jet engines on fighter planes. These are usually a decade or two ahead in terms of advancements. The technology here trickles down to commercial jet engines slowly. Things like Metullargy for blades etc are a closely guarded secret. China and India are pouring billions into research just to get theirs close to even the lower end of what GE has to offer.
One of the figures in the article [1] adds something to this point: military engines have much shorter lifetimes. So it seems it's not just "trickle down" technology, there's also some redesign for reliability.
A commercial engine can operate for a cumulative 1 year between overhauls, according to that figure, as of 2010. The military ones last 1/10th as long. I can only imagine how much more challenging it is to iterate on designs when you are dealing with problems that take 10 times longer to manifest.
This is the way to go, pretty much solves, 404 resource not found or route not found. But you will get laughed at by so called architectural dogmatists. Remember we aren't really doing REST, it's just RPC and let's call it that.
Shoehorning http protocols error codes as application error codes, drinking the cool aid and calling it best practice is beyond bizzare.
Whenever I see a DB written Java, I run, very fast and very far away.
I've never had good experience with these implementations. If you say, the DB isn't performing well, the only answer you get is, well you forgot to tune these 1000 knobs and good luck if your data doesn't fit in RAM.
For some reason I feel your DB in a text file, would fare just as good as these given the same memory and resources that these Apache/java DB servers demand.
I think the reality is that it's too costly to put together a process that filters better. This has been deemed "good enough" and they can fire you if the filter didn't work properly.
58MB for a hello world doesn't not seem small to me.
58MB might not seem much but we used to have entire games in a few MB.
You might argue it doesn't increase that much after 58MB, I don't know what is this good for. I want my command line apps to be lean, I don't care about decoupling source and deno binary on a server side program. I don't see the benefits personally.
this is a bit of a mischaracterization of what's being claimed in the post, all they were saying about binary sizes is that their updates have resulted in SMALLER binary sizes when compiling compared to the previous versions, i.e. they're noting an improvement. nowhere on this page nor any linked from it do they claim they make "small binaries" (that i can find! could be wrong), and you even had to click through their example dedicated to noting this improvement to find the 58mb number you keep mocking.
if you wanted to argue that point, I'd suggest you compare the other solutions that exist today to compile nodejs projects into single executable binaries to be able to have a discussion on why you consider their progress lacking. it's a reasonable point that disqualifies a lot of use cases for these types of tools, but I don't think the conversation was framed from that perspective.
