jemalloc 5.2.1 vs mimalloc v3.2.8 in Rust software processing hundreds of Terabytes. Could not measure a meaningful difference, but mimalloc would release freed memory to the OS a lot sooner and therefore look nicer in top. That said, older mimalloc from default rust crate would cause memory corruption with large allocations >2Gb in about 5% of the cases. Stuck with battle hardened jemalloc for now.
I'm saying it's not good enough to write code yet, but good at explaining code. If it can't that means I messed up and I need to make it clearer. Once it's explanation and my meaning line up, the code is good enough and I move on. Meta point is that people are using AI for the wrong thing. It's great at consuming, not creating.
Early in 1999 my 1st build was a Celeron 300A on Asus P2B-LS overclocked to 450. Later upgraded to 1.4Ghz and 512MB ECC RAM. Much later running FreeBSD as a home server probably till 2015 when the power supply finally gave out, I wish I kept it. Got me through the capacitor plague and was competitive with Pentium 4 for a while. Absurdly stable and quite snappy with a 10k SCSI system drive. Would love to install Windows 98SE again on it and play some Unreal Tournament.
It's decent at explaining my code back to me, so I can make sure my intent is visible within code/comments/tracing messages. Not too bad at writing test cases either. I still write my code.
Been doing Rust lambdas for 4 years now, Rust is absurdly fast, especially when compared to non compiled languages. If anything, Rust is even faster than those benchmarks in real world workloads.
I prefer developing Rust on FreeBSD, memory allocator, scheduler, network stack, kqueue, dtrace and other instrumentation are all superior than the Linux counterparts. What's missing for you?
My Retina MacBook Pro lasted over a decade, that's 200$ a year plus $50 battery replacement and $8 speaker. It still runs fine. Macs are an absurd value/quality for money. If M series Macs run this well, no one else comes even close.
This, fsync() data corruption, BitterFS issues, lack of Audit on io_uring, triplicated EXT2,3,4 code bases. For the past 20 years, every time I consider moving mission critical data from FreeBSD/ZFS something like this pops up.
Well, when you have a bad idea you want to implement but don't want to take responsibility for it, you keep on hiring consultants until you hear what you want to hear. Quality of the consulting is irrelevant and interns or AI will do just fine. When the project inevitably implodes, you blame the consultant. Your own employees will give you advice on what's best for the company, not necessary what's best for you so you stand on their neck until they quiet down and learn their place. By the time anyone figures out what happened you already moved on with outstanding resume bullet point.