I wrote and operate a high throughput go service with somewhat tight memory requirements. It became impracticable to try tuning the memory footprint to avoid OOMs while balancing gc pauses with just the GOGC flag. I'm happy to say that I started using the soft memory limit shortly it landed and it's been a game changer for us.
Only if you ignore all the compiler extensions, that everyone that doesn't care about reading the standard, thinks are part of C.
Get ready for K&R compatibility removal on C23, with improved generics, type inference and lambdas probably landing on C26.
C is actually a good example, given that it shares authors with Go, which at the time also decided to ignore what systems programming languages have been doing since 1958 outside Bell Labs.
C was barely feasible on a PDP-11, so I can forgive it a lot, but we can afford powerful languages now that CPUs are thousands of times faster while brains are pretty much the same.
What do you mean barely feasible? C is basically a slightly abstracted/elevated syntax with a particular calling convention on assembly language, and PDP-11 is just a computer (that i remember too).
I’m under the impression that the speed and memory of their PDP-11 were barely enough to run their C compiler, considering that Emacs was considered a heavyweight app and S-Algol had to target a virtual machine instead of native code.
Yeah. It is extremely frustrating when a whole community of people keep telling you "you are dumb for telling us you need this feature" and then you later watch that community celebrate the addition of that feature when the narrative changes and they finally realize what the feature was actually for. (FWIW: I don't care enough about Go to know the status / history of this feature; I am just commenting on this discussion.)
One ridiculous example I remember (and which tends to surprise people who have a more limited context of the past): MySQL seriously used to have a page of their documentation dedicated to why views were a bad idea and there was a good reason why their database hadn't implemented them. Of course, they eventually realized why people wanted them, so they are both now implemented and the page telling you why you shouldn't use them is gone.
I didn't know about the anti-view sentiment. I do remember them arguing against any need of foreign keys at all, then after they implemented them poorly arguing about limiting their use as they were just "useless overhead". Full transaction safety (aka ACID) was "for banks" not the rest of us. Silently truncating input was de rigueur, blissfully accepting 'Mary had a little lamb' into an integer column happily stored 0, and handling concurrent transactions with MyISAM? Fuhgeddaboutit.
Properly aligned 64 but integer types. That is _the_ feature I’m planning on using. Finally allows me to remove a custom implementation I had to write.
