161–170 of 218 posts
Earlier quoted context omitted.
Because why?
Virtual memory gets rid of a lot of fragmentation issues.
Earlier quoted context omitted.
Because in C, every allocation incurs a responsibility to track its lifetime and to know who will eventually free it. Copying and moving buffers is also prone to overflows, off-by-one errors, etc. The generic memory allocator is a smart but unpredictable complex beast that lives in your address space and can mess your CPU cache, can introduce undesired memory fragmentation, etc. In Java, you don't care because the GC…
No. Look up Arenas. In general group allocations to avoid making a mess.
Earlier quoted context omitted.
CVE are important but there’s also a lot of theatre there. How many are known exploitable? Most aren’t if you follow threat intel. Most of the Internet infrastructure is running c/c++ and is very safe.
It's fine to have a sober view of the severity, but we can hopefully agree in general that writing any program in C or C++ that faces the internet requires extreme caution.
Earlier quoted context omitted.
I propose that we start taking the appropriate amount of professional responsibility. That includes being honest about the actual costs of software when you don’t YOLO the details. Zero UB is table stakes now - it didn’t use to be, but we don’t live in that world anymore. It’s totally fine to use C or whatever language for it, but you are absolutely kidding yourself if you think the cost is less than at least an orde…
Thankfully the new cybersecurity laws will help here, when companies map production costs to languages, the needle will keep moving away from those that tank security budgets.
Good C code will try to avoid allocations as much as possible in the first place. You absolutely don’t need to copy strings around when handling a request. You can read data from the socket in a fixed-size buffer, do all the processing in-place, and then process the next chunk in-place too. You get predictable performance and the thing will work like precise clockwork. Reading the entire thing just to copy the body o…
Why does "good" C have to be zero alloc? Why should "nice" javaesque make little sense in C? Why do you implicitly assume performance is "efficient problem solving"? Not sure why many people seem fixated on the idea that using a programming language must follow a particular approach. You can do minimal alloc Java, you can simulate OOP-like in C, etc. Unconventional, but why do we need to restrict certain optimization…
But we use different approaches for different languages because those languages are designed for that approach. You can do OOP in C and you can do manual memory management in C#. Most people don't because it's unnecessarily difficult to use languages in a way they aren't designed for. Plus when you re-invent a wheel like "classes" you will inevitably introduce a bug you wouldn't have if you'd used a language with proper support for that construct. You can use a hammer to pull out a screw, but you'd do a much better job if you used a screwdriver instead.
Programming languages are not all created equal and are absolutely not interchangeable. A language is much, much more than the text and grammar. The entire reason we have different languages is because we needed different ways to express certain classes of problems and constructs that go way beyond textual representation.
For example, in a strictly typed OOP language like C#, classes are hideously complex under the hood. Miles and miles of code to handle vtables, inheritance, polymorphism, virtual, abstract functions and fields. To implement this in C would require effort far beyond what any single programmer can produce in a reasonable time. Similarly, I'm sure one could force JavaScript to use a very strict typing and generics system like C#, but again the effort would be enormous and guaranteed to have many bugs.
We use different languages in different ways because they're different and work differently. You're asking why everyone twists their screwdrivers into screws instead of using the back end to pound a nail. Different tools, different uses.
Earlier quoted context omitted.
It's a double-sided coin. LLMs are probably the best way to learn programming languages right now. But if you vibecode in a programming language that you don't understand, it's going to be a disaster sooner or later. This is also the reason why AI will not replace any actual jobs with merit.
> LLMs are probably the best way to learn programming languages right now. Books still exist, be they in print or electronic form.
Earlier quoted context omitted.
> Cost is a useful metric because it reflects a number of relevant things: Time to develop, effort to maintain - yes, but also people turnover, required expertise levels, satisfaction, and so on. Whether or not you like it, you have to care about cost if you want to make rational decisions. I'm not talking about assigning a Euro/Dollar/Yuan value to each hour spent on a project, but you need a rough idea about the si…
I don't have time to respond to all of this, but let me just say that you seem to be under the impression that it is somehow my responsibility to "win you over" and convince you to use Rust. I have stated very clearly that that's not my point. My point is that we should all stop lying about the actual cost of delivering reliable software written in C or C++, and in particular that we as an industry need to stop downp…
Whether you realize it or not, you are an advocate and you are doing a very, very poor job of it.
Earlier quoted context omitted.
I believe that the fanatics in the rust community were the biggest factor. They turned me off what eventually became a decent language. There are some language particulars that were strange choices, but I get that if you want to start over you will try to get it all right this time around. But where the Go authors tried to make the step easy and kept their ego out of it, it feels as if the rust people aimed at creati…
> But where the Go authors tried to make the step easy and kept their ego out of it That is very different to my memories of the past decade+ of working on Go. Almost every single language decision they eventually caved on that I can think of (internal packages, vendoring, error wrapping, versioning, generics) was preceded by months if not years of arguing that it wasn't necessary, often followed by an implementation…
Earlier quoted context omitted.
The safer the C code, the more horrible it starts looking though... e.g. my_func(char msg[static 1])
Meanwhile, in Modula-2 from 1978, that would be PROCEDURE my_func(msg: ARRAY OF CHAR); Now you can use LOW() and HIGH() to get the lower and upper bounds, and naturally bounds checked unless you disabled them, locally or globaly.
It is as if just pointing this out already antagonizes people.
Earlier quoted context omitted.
It is - like everything else - nice because you, me and lots of others are used to it. But I remember starting out with C and thinking 'holy crap, this is ugly'. After 40+ years looking at a particular language it no longer looks ugly simply because of familiarity. But to a newcomer C would still look quite strange and intimidating. And this goes for almost all programming languages. Each and every one of them has wa…
I agree that the first reaction usually is only about what one is used to. I have seen this many times. Still, of course, not all syntax is equally good. For example, the problem with Vec > for a 2D array is not that one is not used to it, but that the syntax is just badly designed. Not that C would not have problematic syntax, but I still think it is fairly good in comparison.