Is the C family finally obsolete?

Apart from purely recreational, educational or academic purposes, is there any case where beginning a new project in C, C++, etc. is the best choice? Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes? Which languages do you think should (or shouldn't) replace C family languages for various fields (e.g. should OSs prefer a different language to performant graphics code)? For those who claim C and C++ aren't obsolete, do you think they ever can be obsoleted? What would be required?

C has been obsolete for a long time. There's decades worth of inertia, however. There are many reasons you can't just flip a switch and use any of the better alternatives.

>>26622 >There are many reasons you can't just flip a switch and use any of the better alternatives. Can you list a few of the biggest reasons then? If you're making a new project, what's the issue with inertia?

>>26621 >Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes? Can it be fast enough? Probably. Can it be almost as fast? I'm not convinced. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html >should OSs prefer a different language to performant graphics code)? A serious (non-hobby and non-academic) OS kernel should be in a non-GC language like C, C++ or Rust IMO. >For those who claim C and C++ aren't obsolete, do you think they ever can be obsoleted? What would be required? If you don't consider Rust to be part of the "C family," then I think it is the strongest contender.

>>26628 For the sake of this thread, I won't consider Rust part of that family as it is memory safe. The two big motivators for my view are that: - C (by default) allows code to have memory-safety issues, unless you take extreme precautions (which in most cases seems to me to be infeasible or a waste of time if you could just use a memory-safe language instead) - C became popular around 40 years ago and we have learned much about designing languages for ease of use and error reduction since then.

>>26621 I think while C can produce fast code by modern standards, I think technology has moved on to the point where speed is going to be down to maximising all the cores/threads and memory your system has. You can still do that in C, but concurrency is notoriously easy to get wrong and confusing so I think it pays to go more abstract in the long run these days. I wouldn’t be surprised if that, while C can make individual threads faster with heavy optimisation, functional programming’s inherent and fundamental abstractions (I.e immutable states on a state machine) could end up faster in the long run for most people as it’s able to more easily utilise the vast system resources we have, at the same time those system resources being so vast means I doubt the cost of that abstraction ends up being very high in real world terms even in a thread by thread comparison with C code. It’s actually kind of weird how boards like /g/ still make such a big deal of SICP but also have the attitude that programming in a systems language is the only way to program applications even on modern computers where it’s impossible to properly utilise every clock cycle manually in any reasonable amount of time, just because it avoids “bloat”. Take the Abstract-pill, learn functional programming and use your computer as a tool for expression, instead of being a programmer.

>>26621 Well, to be honest I think C and C++ will live strong as long as our civilization exists as we know it (that is, as long as ISO exists). C/C++ are used everywhere : OS, servers, embedded, performance critical applications where you cannot afford to have random lags caused by GC. I like Rust, but the sad truth is that it is nothing but a toy. Why ? Because the safety it provides vanishes each time you have to open an unsafe block, which is quite often (if you need to work in said computational areas). On the other hand, C++ has evolved to provide safer memory operation with smart pointers and is set to have modules in std=20. I don't mention C, because it has not any real contender, we'll see about Zig in a few years.

>>26631 >Well, to be honest I think C and C++ will live strong as long as our civilization exists as we know it (that is, as long as ISO exists). I also think that this is the truth, as sad as it is. C was a great language and used everyhwere, some people refuse to let it go (for reasons that are beyond me) but it's time to move on and learn from what we learned from C. As you said, Zig could be a great alternative in the future but we'll have to see if it takes off or not. As for myself, I like C, but I also see that it's dated so I choose to use a modern language for new projects. >C/C++ are used everywhere : OS, servers, embedded, performance critical applications where you cannot afford to have random lags caused by GC. They also can't afford to switch to a language like Rust because rewriting software is expensive, which might be why most software is still written in C/C++ and not a newer language (could be something else than Rust). >I like Rust, but the sad truth is that it is nothing but a toy. Why ? Because the safety it provides vanishes each time you have to open an unsafe block, which is quite often (if you need to work in said computational areas). Sure, the safety it provides vanishes. I see this being said a lot but to me it's not really an argument against Rust. Rust tries to provide memory safety as much as possible, but memory safety can't be achieved everywhere all the time. Those cases are what the unsafe blocks are for. If you open an unsafe block you're supposed to start thinking about memory safety very carefully and proove why the code you wrote is memory safe. This is a step up from languages that don't provide the same kind of memory safety as those require you to think this hard about it everywhere in the code, which is tiresome and people get lazy so they tend to not realize or just plainly don't care. The chance of this happening is reduced with Rust.

>>26630 >learn functional programming and use your computer as a tool for expression, instead of being a programmer Wise words, I completely agree.

If you are going to build a new operating system what language would you use if not C? Considering that you cannot use standard libraries or built in functions that make calls to another operating system?

>>26642 There are examples of OS being written in Lisp and C++. No reason to use only C.

I share the enthusiasm for higher-level, functional languages expressed above, but I wonder that Ada is rarely brought up in this kind of discussion (and always, it seems, by the same few fanatics). If for your project you need to write lowish-level, performant code, yet you don't feel like spawning the next Heartbleed, is there a more obvious choice than Ada? Surely D or Rust can do the job, and Zig someday, but they buy you only a fraction of the guarantees that Ada gives you, for similar performance. Am I mistaken somewhere? I've given it a spin recently, and while it's verbose to write, its type system has features that even my dear ML-family languages fatally lack.

memory safety is such a fuarrrking meme. just stop being a soykafty programmer. memory is the programmer's responsibility, not the language's.

>>26647 The more you have to concern yourself with inane trivia, the less time you have for useful concerns. Furthermore, the possibility of getting it wrong is basically the certainty of getting it wrong with enough time.

>>26631 >I like Rust, but the sad truth is that it is nothing but a toy. Why ? Because the safety it provides vanishes each time you have to open an unsafe block, which is quite often (if you need to work in said computational areas). People act like rust is the only language that has safety/unsafety. ANY language that provides memory safety in its normal day-to-day use has to provide an escape hatch if it wants to provide certain capabilities. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/unsafe https://blogs.oracle.com/javamagazine/the-unsafe-class-unsafe-at-any-speed C# and Java, two of the most widely-used GCed corporate languages, both provide an unsafe mechanism for added memory usage. Languages that don't provide such capabilities such as Python basically just have to call inherently unsafe C code to achieve certain things. Are they toys?

>>26645 Ada front loads your effort and makes you think a lot about design and specifications before you write implementation. C, C++ and their imitators encourage deferring those problems to a later time or doing it on the fly. If you’ve got the inclination, you should graphically model a popular project’s code base and see what a fuarrrking train wreck it is. Ada makes you eat your veggies and go to the gym or you can choose hacker-Lang and smoke meth and beat it on the couch. I think you know what choice the Hacker News hipster devs have made. Also, Ada is not as unpopular as you think. It’s just not a popular hobby-language, so you don’t see it on GitHub. Subway control systems aren’t open source and their authors don’t write big-thonk pieces about their hot, new stack on Medium.

>>26644 I can't believe we've gone this long talking about low-level programming and OS programming without mentioning Ada or Oberon...

>>26645 >>26660 As much as I love Ada I think it's fatal flaw is it's verbosity. Isn't there a way to get the guarantees of Ada, the Inference of Haskell, and the ease-of-writing-and-reading of Python? Ada is a lovely language with lovely typing features, a great community, and bullet-proof safety, but it is what I would consider needlessly verbose at times.

>>26662 Well, that’s basically what C++ tries to be. A solution for all problems for everyone. I wouldn’t be in a rush to say that has worked out. In exchange for time-saving conveniences, low level control, and an extremely powerful way to specify complex behaviors through templates, you also have something that’s very hard for anyone to understand. Personally, I think you are better off deciding if you need well specified behavior, direct control of memory, or ease of production, and go with some thing that suits that problem well. You really can’t escape from the essential complexity of having to tell the computer how to do something complicated Koka, Danny, and F* are cool, though.

>>26656 That's entirely different as C# and Java are not systems programming language. It is not their primary goal to be fast and manage memory manually. It's ok for them to have a way to do it (as python can have direct access to memory, and I am sure JS too) Rust claims to be a system programming language with safety. The thing is : to be useful as a system programming language, Rust needs unsafe code. The same is true in C++ where you can't always use smart pointers. So why pretend ?

>>26690 >The thing is : to be useful as a system programming language, Rust needs unsafe code. Sure, that's the case, I won't argue about that. What I will argue about is how everyone neglects the safe part of Rust, treating it as if you just wrap your whole program in a huge unsafe block. If you need unsafe operations, go ahead and open a block. If you don't, then don't open one. Every unsafe block you open should be documented with the reason as to why the programmer thinks this is safe but the compiler is unable to check it for safety. If you don't use an unsafe block the compiler enforces you to write safe code. This is good, right? Isn't this better than having no such safety guarantees? Is it really better to constantly be in unsafe land and not have safe code enforced by the compiler? I'd clearly argue that no, this isn't better. I'd rather have 50% proven safe code and 50% probably safe code than 100% of code that's probably safe. It limits human error by a lot, how is this bad? If you're arguing that C++ has smart pointers then I'd argue that Rust has those, too. There has to be more reasons why people hate Rust, this safety argument can't be the only one.

>>26695 also safe rust is threadsafe. smart pointer cpp is not. in fact, even most of the memory safe gced langs arent threadsafe.

>>26621 So I know the OP talks about excluding academic purposes, but I work in a (corporate) research group dealing with VM implementations and we use Cpp for the VM. I will say that C/Cpp are actually god awful languages -- C with its terrible memory safety, and Cpp due to all the cruft attached to it (C compatibility, 4537 ways to do something etc.). Most exploits and bugs come from memory safety -- >>26647 claims that memory safety is up to the programmer, which reminds me of something really asinine from Drew Devault who says "C programs can be secure! Take a look at seL4 which is formally verified OS written in C" [1]. No. I've worked with the developers of seL4 and C was begrudgingly chosen as the language to implement the microkernel. In fact the entire paper uses Haskell snippets of code as originally they had implemented a prototype in Haskell but required more performance and hence very carefully spent a lot of man hours to rewrite the Haskell code to C _and then_ formally verified it. The rest of the world does not have the luxury or the time to formally verify a piece of code. It's honestly a pretty absurd argument. The point being that memory safety (and general safety mechanisms) is no joke and should seriously be considered when starting a new project. The C/Cpp vs everything also reminds me of this great article [2] that argues that C/Cpp etc. actually have a lot of cruft associated with them and the abstractions they were built on perhaps need to be re-examined. > Immutable objects can simplify caches even more, as well as making several operations even cheaper. Sun Labs' Project Maxwell noted that the objects in the cache and the objects that would be allocated in a young generation are almost the same set. If objects are dead before they need to be evicted from the cache, then never writing them back to main memory can save a lot of power. Project Maxwell proposed a young-generation garbage collector (and allocator) that would run in the cache and allow memory to be recycled quickly. With immutable objects on the heap and a mutable stack, a garbage collector becomes a very simple state machine that is trivial to implement in hardware and allows for more efficient use of a relatively small cache. This honestly opened my eyes to the what we could achieve if we have more specialized caches. On the other hand, mitigations for Spectre/Meltdown etc. have large overheads (~20-30% for older Intel CPUs). People used to joke about "We can just run everything in a (language) VM now since the performance is comparable" and that's honestly not too far-fetched now. I like Rust and have used it for some of my own projects, but it needs to sort some stuff out imo: there is no formal specification for the language -- the language is literally defined by the latest commit on master in the Rust repository; as well as a lot of Rust standard lib owes itself to Cpp (memory model and atomics for example). I think it needs to reevaluate certain choices. Ada is pretty cool but honestly very verbose. The US DoD in fact now prefer C/Cpp programmers than Ada programmers (even though Ada was a US DoD project) as it is easier to get C/Cpp programmers and teach them how to not write bad code (see MISRA C/Cpp for example), than it is to find good Ada programmers/teach Ada to programmers. I remember doing Ada for a University course 5-6 yrs ago and there was basically no supporting documentation or help guides other than the Wikibooks (which is pretty good) and literally the (very verbose) language manual/specification. As an aside, if your project does not require insane performance or some real-time guarantees, then just use a GC'd language because the entire abstraction for memory makes life so much easier to program in and then you can focus more on the actual implementation than worrying about memory leaks or whatever. >>26628 links the computer benchmark shootout games and honestly, the Java programs are pretty simple to grok and in fact are not too bad at all. The JVM engineers do some really clever engineering with their JIT compilers for Java. [1]: https://drewdevault.com/2021/02/09/Rust-move-fast-and-break-things.html [2]: https://queue.acm.org/detail.cfm?id=3212479

If you count C#, yes. .NET is still extremely popular and good.

>>26621 >is there any case where beginning a new project in C, C++, etc. is the best choice? if you're developing for unix like OS, for obvious reasons C integrates really well and typically brings mininal baggage. >Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes? i don't think security is a language problem. we're blaming the tool for the inadequacies of the user. C does make it easier to write unsafe software but at the end of the day how secure a program is depends entirely on how its written, not on the language being used. >Which languages do you think should (or shouldn't) replace C family languages for various fields most modern languages are heavily bloated and bring an insane amount of baggage. things that should be seperate tools, gets pushed into the language itself.

>>26859 C-Unix integration is certainly a thing, but it doesn't by itself make C the best choice for a project. It will if, for that project, you need some benefits of the language-OS integration that you can't get any other way. What benefits does the integration bring, exactly? This is beyond my expertise, but I suppose two big ones are access to system calls and ability to dynamically link with system libraries. For the first one, am I wrong to believe that FFI accomplishes that also? For the second one, as an extreme example, you can transpile from a higher-level language to C. Even when the project calls for Unix integration, there is room for some other language to come out on top of C, depending on the rest of the project's requirements. >i don't think security is a language problem. we're blaming the tool for the inadequacies of the user. I may be making a mistake in replying to this, but let me put it this way: if there were programmers who can write insecure programs and programmers who are mathematically incapable of writing them, then we'de be stupid to ever let the first kind even touch a keyboard. Unfortunately, only the first kind of programmer exists; however, we do have languages which allow every conceivable vunlnerability, and languages where large classes of vulnerabilities are impossible to write.

>>26621 can one write efficient assembly for a broad range of CPU architectures without C?

>>26867 Without C? Certainly. In traditional assembly? No. Maybe you could hand write some high-performance LLVM assembly though.

I actually like doing my soykaf in c/c++, but maybe that is just nostalgia talking

I'm really surprised that no one has mentioned Go yet.

>>26621 >For those who claim C and C++ aren't obsolete, do you think they ever can be obsoleted? What would be required? The few "exotic" operating system projects I've run into always use C, until this is no longer the case it's not obsolete. >>26630 Nobody on /g/ takes SICP seriously, and I doubt most of the board's population has read it in a long time. For as long as I've been on /g/, SICP has always just been a joke. >>26873 Wasn't there some issue where Go didn't have proper exception handling implemented?

>>26903 >SICP has always just been a joke. Now that's what I call brewing soykaf! Here is a (you). That take is hotter than a stolen tamale.

>>26905 I meant on /g/. I've only ever seen memes about it on there and never any discussion about what it's actually about.

>>26903 go has error values, not using try-throw-catch-finally doesnt mean it doesnt have error handling or whatever you're trying to say

>>26621 > Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes? Yes, easily, esp nowadays when we have type theories strong enough to talk about regions or some version of linearity. > Which languages do you think should (or shouldn't) replace C family languages for various fields (e.g. should OSs prefer a different language to performant graphics code)? Ideally we'd have a language that can abstract both up and down. For operating systems a language which can go both up and down would allow the OS to be more unified and scale as the project grows. For this, some derivative of LISP would be ideal as macros and hackability help us scale down and above. >>26873 Well Go is not a replacement for C. It appeals to C people do to being... well. But for any practical applications you are better off using something like OCaml, which is where Go is heading to in 5 years (They already caved to generic, they will eventually cave to adding Sum types, then....). >>26914 Perhaps they meant that go doesn't handle errors well. How go implements error handling tends to force the programmer to remember to handle it every time, as they can't build abstraction around it due to the lack of generics and sum types (for reference see the either type in Haskell or OCaml. Further examples of a weaker kind, Maybe/Option, can be found in Java8+ as well, etc.). >>26867 Part of the issue is that hardware tries to optimize itself for a C style machine along with a lot of work going into making C particularly fast. Thus C tends to hold up fairly well performance wise. In a world where C didn't dominate the market C would be nowhere near as fast as it is now due to the market encouraging optimizations that benefit C while discouraging optimizations that come at the cost of speed for C.

>>26921 >a derivative of LISP would be ideal Racket is pretty useful. Now that it's on Chez Scheme, the performance is perfectly adequate for application-space tasks. Clojure is also nice. more I've used it and F#, though, the more I think FP on top of a OOP-centric runtime (JVM/CLR) is just a mistake. If I'm using thinly-sugared method calls on the Java String class to make a program work, then why am I not just using Java? With regard to Golang, it is really the Plan9 C compiler by Google. Now that Rob Pike doesn't really seem much involved, though, I don't know what direction it's going. It's 100% Google property, though, so I avoid it, despite the fact that it's usually a very good choice for utilities or small, networked services. >>26906 Nobody talks shop on image boards with respect to programming. The reasons are 1) users tend to be students or inexperienced people 2) image boards are places to giggle over anime tibbies and maymes. It's kind of like the writing on the wall of a gas station men's room. It's sometimes funny and fun to participate, but the medium is not conducive to conveying well-thought-out content.

>>26921 >In a world where C didn't dominate the market C would be nowhere near as fast as it is now due to the market encouraging optimizations that benefit C while discouraging optimizations that come at the cost of speed for C. What is an example of this?

>>26922 >Nobody talks shop on image boards with respect to programming. The issue with lainchan specifically is too much tone policing. Beginners and trolls learned to be polite and mods reacting only to the tone of posts will delete the less polite responses from experienced developers. So all you are left with is very polite beginners and trolls leading each other in circles.

>>26928 Someone else wrote that, but if I had to guess, modern RAM presumes tightly-packed data (ie struct-like) and optimizes for its access. A LISP-centric RAM would probably focus on making pointer-chasing efficient. I would think that there could be CPU instructions that might be nice for logic programming, but I don't know nearly enough about their implementation details to guess what that might be. >>26929 Tone policing is *everywhere*. Case in point, I was solicited on GitHub to review a student's FOSS code because I'm a professional in the relevant industry. I agree, and everything is fine, then some admin tells me that I have to sign some fuarrrking contract with broad, unspecific requirements to be "inclusive" or some soykaf. Bitch, I bill at $120/hr and am doing unpaid volunteer work YOU asked me for, and now you want me to sign a pretend-legal document saying that I promise not to say bad words which means . . . whatever the fuarrrk some webshit FOSS-groupie thinks it means? Pearl-clutching internet hall monitors can get fuarrrked. Check out Unix-Haters https://web.mit.edu/~simsong/www/ugh.pdf and get a taste of what 'computer' people where like 30+ year ago. Zero sentimentality. No lip-service to tolerance. You straight -up told Dennis Ritchie, a giant of a time long gone, that his OS and language is a fuarrrking virus, and he told you that your opinions are soykaf. My pet theory is that the industry is full of grifters who don't want to write software, but want to write, blog, and lecture on stage *about* software. Socrates is dead, and now there's just a bunch of sophists in the forum. That's my word.

>>26929 >>26922 The discussions here are incredibly well thought out and valuable to learning when the tone of posters is not soykaf. The C language and Lisp threads are both great sources to see neat tricks and share neat ideas, a helluvalot more than on four, exactly because the tone is: "be civil, be nice". WTF is this nonsense about trolls and beginners? The only trolls so far have been very poorly behaved lains that throw soykaf over the littlest things, the only beginners I've seen are threads asking "how do i start?". The fuarrrk are you on about? >>26930 I know you'll want to lump me in with the "hall monitors" but I don't see the value in soykaf-talking and being an ass-hole, especially not to someone who's trying to get into technology. Being nice doesn't have to mean walking on egg-shells, but being an asshole doesn't help jack either. If someone asks you to help them fix their car that doesn't mean you have to call them a retard every other nut or bolt. Someone doesn't learn better if you call them a fuarrrkwit for every small mistake they make. The lame excuses I hear about substantive dipshittery sounds like it's own kind of pearl-clutching in my opinion.

>>26932 >The fuarrrk are you on about? You just saw an example. >>26930 either doesn't know the difference between ram and cache or he's just making soykaf up. Either way the board has been so sterilized there's nobody left to correct him.

>>26949 He's not wrong, but I'll explain why. I don't want to write a long post, so I'll only discuss memory tagging. The Lisp Machines tagged memory, knowing what everything is; this not only allows prefetching pointers, but there was CDR-coding, an optimization for linked lists which stored them sequentially, until they couldn't be. Other machines also had tagged memory. Of course, the C language has no use for memory tagging, so this is rare again. >Either way the board has been so sterilized there's nobody left to correct him. Why not leave, then?

>>26932 >>26949 You know what you did, and you know I'm right. Post the yard sign, weenie.

>>26928 >What is an example of this? It's much easier to change a serial map to parallel map than to parallelize a serial loop. There used to be hardware that interrupts on overflow. This allowed a program to abort on bad arithmetic or upgrade to bignums. That feature is dead, because C doesn't make use of it. There's also expensive safety features that C requires. Virtual memory is only usable in userspace and requires hardware and OS support, but the isolation provided by it is only useful for languages that expose raw pointers. W^X is only usable in userspace and requires hardware and OS support, but is only useful for languages that expose raw pointers. ASLR is only usable in userspace and requires hardware and OS support, but is only useful for languages that expose raw pointers. >>26949 >doesn't know the difference between ram and cache What part of what he said made you think that?

>>26971 >There used to be hardware that interrupts on overflow. This allowed a program to abort on bad arithmetic or upgrade to bignums. That feature is dead, because C doesn't make use of it doesn't x86 have integer overflow flag support? you'd just have to check the flag on every operation. (automatically done by the interpreter or compiler) with branch prediction it may not even slow things down that much

>>26952 >memory tagging You realize that's a CPU change. RAM is still RAM. >the C language has no use for memory tagging, so this is rare again This is not an example of optimizing for C though, it is simply not going out of your way to optimize lisp. >>26971 >It's much easier to change a serial map to parallel map than to parallelize a serial loop. I have no idea what this is supposed to mean. >There's also expensive safety features that C requires. >only useful for languages that expose raw pointers >only useful for languages that expose raw pointers >only useful for languages that expose raw pointers You realize all the interpreters, vms, operating system your high level languages run on are written in languages that expose raw pointers. Something has to touch the hardware at some point dude. >What part of what he said made you think that? The reason "pointer chasing" is slow is because cache wants things to be sequential. Not because random access memory wants things to be sequential.

>>26974 >I have no idea what this is supposed to mean. Loops in low level languages, like C, are hard to parallelize because the language assumes loops must run in order. Low level languages, like C, are usually garbage to optimize because it's near impossible to separate desired behavior from merely incidental behavior. >You realize all the interpreters, vms, operating system your high level languages run on are written in languages that expose raw pointers. Something has to touch the hardware at some point dude. The only part that directly touches the hardware, the OS, can't use any of these safety features. This was already pointed out individually for each safety feature, 3 times, in the same post.

>>26975 >Loops in low level languages, like C, are hard to parallelize Oh you mean map like map/reduce, not hashmap. And how would hardware changes help? >The only part that directly touches the hardware... Ok but your userspace interpreter or runtime environment still needs to organize memory somehow. You are not free from pointers just because the pointers are happening in a place you can't see.

>>26977 >Oh you mean map like map/reduce, not hashmap. And how would hardware changes help? Vector parallelism would be more common now than SIMD, which C still is like kicking dead whales down the beach at using automatically, if low level C didn't guide hardware into a slump. >Ok but your userspace interpreter or runtime environment still needs to organize memory somehow. The kernel already does all of that. C userspace programs do not touch or organize memory directly. 'mmap' is not low level. Everything is done through a level of indirection. There are system calls or virtual memory addresses in the way. IIRC, there are two levels of address translation on Intel processors since segmentation is adding a bunch of zero offsets in modern systems. Thank you legacy system. >You are not free from pointers just because the pointers are happening in a place you can't see. The issue is not that pointers should be avoided, the issue is that the OS and hardware require special support to protect C programmers from themselves in userspace. This special support is slow. This special support doesn't actually work, W^X and ASLR are loose bandages. This special support is not available in the kernel, the most useful, only useful, place for raw memory address manipulation.

>>26979 >>26975 >Virtual memory ... the isolation provided by it is only useful for languages that expose raw pointers. are you sure this is accurate? wikipedia says lisp machines used virtual memory.

>>26979 >Vector parallelism would be more common now than SIMD if low level C didn't guide hardware into a slump. What languages besides C are generating vector instructions then? >The kernel already does all of that. Actually it's the MMU but that doesn't change the point. However many translations an address goes through before it hits physical RAM, your userspace program still has to deal with some kind of memory addresses. Even if your language "doesn't expose pointers", it's still running ontop of a language that does. >the issue is that the OS and hardware require special support to protect C programmers from themselves in userspace. This is the same fallacy. Just because memory manipulation is typically done in C doesn't mean that if C doesn't exist there would be no more memory manipulation.

>>26981 >What languages besides C are generating vector instructions then? Very few, since the hardware support hasn't been around as long. Thanks to C. >>26981 >Actually it's the MMU but that doesn't change the point. The OS sets up the page table and responds to page interrupts. It's joint work between the hardware and the kernel, but the kernel hides all of this from userspace. Nobody but the kernel is seeing physical addresses. The kernel handles memory organization. >This is the same fallacy. Just because memory manipulation is typically done in C doesn't mean that if C doesn't exist there would be no more memory manipulation. There is no fallacy. Isolation by virtual memory, ASLR, and W^X put overhead on all userspace programs so that C programmers can: pretend they have a flat address; be protected from their own language. >>26980 Virtual memory has more than one use. Virtual memory isolates processes, provides a similar memory layout to distinct programs, makes RAM seem larger by swapping out unused memory to storage, and makes loading programs into memory as easy as a page. Today, RAM is cheap enough and scalable enough swap isn't worth having virtual memory. Process isolation only makes sense for userspace algorithms that have access to raw pointers.

>>26988 >Very few, since the hardware support hasn't been around as long. Thanks to C. The first version of AVX shipped in 2011 and that is too new to integrate it? Your argument is not convincing. >There is no fallacy. Isolation by virtual memory, ASLR, and W^X put overhead on all userspace programs so that C programmers can: pretend they have a flat address; be protected from their own language. The fallacy is your implication that without C there would be no need for virtual memory.

>muh C boogeyman killed hardware comparing C to lisp of all language reads like nothing more than a satire. most people here may not wanna hear this, but lisp has never been anything more than an academic language. despite predating C, the only notable achievement of lisp is emacs. and here's the funny part, emacs, the core of it, isn't even written in lisp. its written in C.

>>27012 > what is NASA > what are Lisp Machines

>>27017 > what is NASA Avid users of C++ :^​) > what are Lisp Machines A wasteful irrelevance

>>27012 >but lisp has never been anything more than an academic language. Which is false because there are some good programs made in Lisp or its dialects. >despite predating C, the only notable achievement of lisp is emacs. Which is again false, see Guix. >isn't even written in lisp. its written in C. So? The C compilers aren't even written in C but C++. Chez Scheme is written in Chez Scheme. That's a good enough proof C is not needed. >>27018 Are you brewing soykaf? Just because a language is widely-used doesn't mean it is so good.

>>27018 https://flownet.com/gat/jpl-lisp.html It was removed because of C's own foibles and cost-cutting on training, but it still existed. The story https://www.youtube.com/watch?v=_gZK0tW8EhQ

>>27019 >Guix. overcomplicated spaghetti with barely any practical usecases. >Just because a language is widely-used doesn't mean it is so good. i agree, popularity doesn't mean quality. but where exactly is lisp's quality other than being a academic language. the fastest lisp implementation is still dreadfully slow compared to C, all of lisp's achievement is virtually nothing compared to C. Fabrice Bellard's projects alone send all of lisp into absolute shame. everytime someone talks about lisp, its always theoritical mumbo jumbo with zero practical evidence. even if C didn't exist, i can assure that lisp still would suffer from the exact same irrelevancy it suffers from today. some other language, possibly worse than C would've taken over, not lisp.

>>27026 > overcomplicated spaghetti It has one of the clearest codebases I've seen for a package manager in a while, and it's only as complicated as it needs to be for its purpose and goals. > with barely any practical usecases. You're just trolling at this point. It facilitates not just local package management but deployment of portable bundles, containers, etc. It entirely obsoletes pyvenv and similar programs. It also proves very helpful in trying to achieve build reproducibility, and it's much easier and less annoying to use and package for than Debian's APT. > the fastest lisp implementation is still dreadfully slow compared to C Chicken Scheme and Gambit achieve fairly close performance. The difference is mostly attributable to memory safety features and GC. If you're willing to throw safety and runtime checks out the window, and properly type-annotate your code for specific uses, SBCL can generate code that's just as fast as any contemporary C. I would consider this a bad tradeoff, but you can. > Fabrice Bellard's projects alone send all of lisp into absolute shame. Complete non-sequitur. His achievements are noteworthy but they have exactly nothing to do with programming language comparisons, but rather his skills and knowledge. > exact same irrelevancy it suffers from today. some other language, possibly worse than C would've taken over, not lisp. Considering that C took Fortran's place? It probably wouldn't be any worse than Fortran. Maybe Pascal, which I'd argue to be better than C.

>>27027 >Chicken Scheme and Gambit achieve fairly close performance. they both compile to C ;) also we must have very different definitions of "fairly close" because they are still _multiplications_ away from C performance.

>>27029 > we must have very different definitions of "fairly close" because they are still _multiplications_ away from C performance. Magnitudes are usually what's used as a basic unit of comparison for these sorts of things, as with algorithmic performance.

>>207030 continued Yes, they compile to C. While SBCL compiles to native instructions.

>>27027 >You're just trolling at this point. He's not the one ѕhilling lisp in a c thread.

>>27039 He started >>27012 Also the thread is about C being obsolete, not about C generally. There's another thread for C elsewhere.

>>27041 >Also the thread is about C being obsolete, not about C generally. Oh god this thread is dumber than I thought. OP has never heard of firmware apparently. Or thinks that all computers have a keyboard and mouse. So what's this lisp soykaf then? I'll bet you more new C code was written in 2020 than all lisps, except clojure and elisp, ever.

>>27046 I'll bet more Javascript was written than either. Does that sound like a good argument?

>>27049 >I'll bet more Javascript was written than either. Does that sound like a good argument? Doubtful since C is like three times as old as Javascript. And nobody writes plain javascript anymore anyway, it's all languages that transpile down to javascript. So to answer your question, no that's not a good argument. But then again I don't expect much from this board.

>>27051 Its age doesn't matter. You specifically said "in 2020". > So to answer your question, no that's not a good argument. But then again I don't expect much from this board. Yeah. Popularity has more to do with corporate kool-aid drinking than anything else.

>>27046 you are making a lot of assumptions about who is posting. Why do you suspect it's the OP? Further where are you getting the assumption that OP "thinks that all computers have a keyboard and mouse."? To me it seems that you are making a lot of unfounded assumptions. As for why lisp, lisp has been used successfully in domains various domains. When Multics was made it was considered insane to use such a high level language such as PL/I, but since we've standardized on Unix, I guess it's crazy to assume that we should use anything higher! As for the claim about the amount of lisp code. It would actually surprise me if C code written last year outnumbered the amount of lisp code written in the past 60 years. In the 80's lisp was from what I understand a top 10 programming language. There was an entire industry backing lisp, from AI, to CAD software, algebra systems, compiler research, graphics, ....., the list goes on quite a way. This further compounds if we consider that a bunch of companies use lisp but don't really talk about it much. In fact if we include all s-expression languages this explodes to an insane amount of code. Z3, WASM, and gcc's IR are all expressed in terms of sexps. Further lisp has successfully been used as a compiler choice by a few languages. (if you are the same poster as >>27029, then you would care about this part.). Often it's either scheme or some derivative of CL. A few examples include languages which target ACL2 for it's proof capabilities. the original caml-light which targeted some lisp, and Agda which targets Chez scheme. >>27051 The reason why >>27049 made their argument is becasue you seem to be fond of using popularity as a key argumentation point. It's actually much easier to see qualities of languages if we dissect the actual languages rather than stir soykaf about the uses. As for lisp in general. It's a very powerful language, and if you actually compare the power various ideas give you, it is very easy to draw a conclusion why it'd be a good fit for a systems or OS language.

It's common for C weenies to retreat to popularity, once it's again made clear that C is neither fast, efficient, innate, nor practical. Lisp is older than C, and thus can clearly exist without it. Conveniently, arguing for this asinine tainting by implementation language evaporates when they're reminded GCC and Clang are written in C++. There probably is more C than Lisp, because C requires more code to express the same thing in a worse way. Why shouldn't a language bend to a problem like Lisp?

>>27054 >Its age doesn't matter. You think all software projects are greenfield hobby soykaf on your github or something? The older the language the more legacy codebases that need maintaining pile up year on year. And with C nobody is switching to anything else except maybe C++. >Popularity has more to do with corporate kool-aid drinking than anything else. Yes it's got nothing at all to do with toolchains or resource constraints or availability of talent. I don't know what inconsequential hipster industry you work in but you have my sympathies. >>27055 >you are making a lot of assumptions about who is posting <why are you ignoring the topic??? <why do you assume I care about the topic??? You can't have it both ways. >where are you getting the assumption that OP "thinks that all computers have a keyboard and mouse."? Because the only reason someone would think C is "obsolete" is if they are looking from an end user perspective and completely oblivious to all the compilers, interpreters, system libraries, operating systems, firmware and embedded systems behind the scenes. Or a hobby perspective where everyone wants to use cool obscure languages with exotic paradigms so of course no one writes procedural C anymore derp. >To me it seems that you are making a lot of unfounded assumptions. To me it seems like you are an idiot. >everything that compiles down to S expressions counts as lisp therefor implications Ok dude. >you seem to be fond of using popularity as a key argumentation point What do you think the thread is about. >lisp is the super powerful best langauge and im so smart for using it etc. Rinse Paul Graham's cum out of your mouth.

>>27060 You're moving the goalpost. Stop that. > The older the language the more legacy codebases that need maintaining pile up year on year. Yes... those very same legacy projects where adding any code at all requires days or even weeks of verification to pass the validation processes. That sure is conducive to writing a lot in a short amount of time⸮ >Yes it's got nothing at all to do with toolchains or resource constraints or availability of talent. It does, but it's hardly as if C has the best tooling, or the greatest availability of talent. It's hardly as bad as Erlang's (on both accounts), but it's far from amazing. > Because the only reason someone would think C is "obsolete" is if they are looking from an end user perspective and completely oblivious to all the compilers, interpreters, system libraries, operating systems, firmware and embedded systems behind the scenes. Just because Fortran is still used doesn't make it any less mostly obsolete outside of the few industries where it mainly represents legacy software. There's also no particular reason those systems couldn't be written in microscheme or something similar, save that some manufacturers annoyingly refuse to release specs and only provide an object blob with pre-defined interfaces. All those program examples you give are simply incidental legacy. There is nothing particular to C which makes it an outstandingly great choice for those things. It's actually pretty fuarrrking terrible for most of them and its choosing as an implementation language has directly led to severe security bugs in the past. > Rinse Paul Graham's cum out of your mouth. lol

>>27065 >it's hardly as if C has the best tooling You realize there are 100s of micros that only support GCC and/or have less than 128K, so C is literally the only choice. Not all computers have a keyboard and mouse. Do you even realize how many different microcontrollers are packed into a single laptop and all of them need firmware. Not all computers are x86 either. There are other CPUs and they all need specific toolchains. Basically every CPU invented has a C compiler, therefor everyone uses C. >or the greatest availability of talent Compared to what exactly? What other language are you going to use for a MIPS processor with 56KB of ram? A microPython runtime won't even fit in there nevermind your application code. >There's also no particular reason those systems couldn't be written in microscheme So to summarize, there is a reason because A) nobody knows microscheme so who are you going to hire? And B) there is either no compiler support for the hardware or not enough resources to run a high level language anyway. >Just because Fortran is still used doesn't make it any less mostly obsolete outside of the few industries C is still used everywhere though. Everywhere. The tip of the iceberg is the stuff the end user sees which is now all web and C# and Swift or whatever. But dig down just a few layers and everything is C from that point down to the hardware. >All those program examples you give are simply incidental legacy. Not sure why you're still talking soykaf about a world you clearly have zero experience in.

>>27066 >not enough resources to run a high level language anyway. Even if there is enough resources, C will be more efficient, and it's a bulk game. If you are shipping 1million chips and you can save $1 per chip on RAM by using C instead of microPython then that's $1million saved.

>>27066 > Not all computers have a keyboard and mouse. You keep repeating this like it means something. >100s of micros that only support GCC I mentioned annoying idiotic manufacturers that don't publish specs for a reason. > less than 128K, so C is literally the only choice Not really. There were Lisps for Apple IIs. I'm sure we can do better with modern compilers. > Not all computers are x86 either. Yes... not sure why that's supposed to change anything. Not all Lisps are limited to i386/amd64 > There are other CPUs and they all need specific toolchains. Basically every CPU invented has a C compiler, therefor everyone uses C. We centralized our chain on a bad choice and now we have to deal with it. That's not exactly a ringing endorsement. And transpilers can be used anyway. > Compared to what exactly? What other language are you going to use for a MIPS processor with 56KB of ram? A microPython runtime won't even fit in there nevermind your application code. That means microPython is too fat a language. Scheme is most likely not. Especially without the later revisions. Especially with a clever-enough compiler. > So to summarize, there is a reason because A) nobody knows microscheme so who are you going to hire? Why do people learn/know C? How hard is it to learn Schemes? Much easier than C, so training shouldn't be a problem. > And B) there is either no compiler support for the hardware or not enough resources to run a high level language anyway. The first is solvable if specs are published, the second is solvable via sufficient compiler cleverness. > But dig down just a few layers and everything is C from that point down to the hardware. Which as you have so brilliantly highlighted is pretty much entirely because of a few bad choices that locked everyone into that chain. > Not sure why you're still talking soykaf about a world you clearly have zero experience in. Such strange assumptions you've got. It's unambiguous fact that entire classes of bugs leading to security vulnerabilities would be impossible if C hadn't been chosen. Furthermore, I have worked with C and still occasionally do. >> compilers, interpreters, system libraries, operating systems All of these can be easily made in other languages, save for a few specific hardware bits you'd implement in the smallest amount of ASM possible and then wrap. >> firmware and embedded systems These require more lightweight languages and/or smarter compilers so that you can get a minimal size of output and decent runtime characteristics. > Even if there is enough resources, C will be more efficient, The main reason for that has a lot more to do with the sheer amount of time that has already been spent optimizing and improving C compilers (for hardware that no longer matches the C abstract machine) than because of any quality intrinsic to C > and it's a bulk game. If you are shipping 1million chips and you can save $1 per chip on RAM by using C instead of microPython then that's $1million saved. That's more a problem of microPython's language being too fat, or its compiler being too soykafty. Lowest cost/bidder isn't necessarily a good thing either. Especially when it expressly increases the likelihood of bugs and problems.

>>27060 > Because the only reason someone would think C is "obsolete" is if they are looking from an end user perspective and completely oblivious to all the compilers, interpreters, system libraries, operating systems, firmware and embedded systems behind the scenes. I don't think you know much about compilers or interpreters. A lot of languages targeted C as it was an easy way to get on lots of machines and architectures while leveraging free optimizations C compilers have. With that said, it's much more sensible to target LLVM these days, as you have much better control of what's happening. You get the freedom to chose your calling conventions, padding of structs, better freedom of the ordering of optimization passes, etc. It's very clear LLVM is made to support C, but people compile to this these days as it's a better target with tons of man hours put into it. People don't chose C because it's the best IR to target nor to the suitability of the language. Further if we are talking about interpreters, most people make interpreters in languages they are familiar with. A lot of the times it's for business and written in the language the business is in to maintain said code. When trying to design and make languages C would be a horrible implementation choice for this. >> you seem to be fond of using popularity as a key argumentation point > What do you think the thread is about. As per the OP "Which languages do you think should (or shouldn't) replace C family languages for various fields (e.g. should OSs prefer a different language to performant graphics code)?" "Apart from purely recreational, educational or academic purposes, is there any case where beginning a new project in C, C++, etc. is the best choice?" "Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes?" Hence the Rust and Lisp talk earlier. Due to C being unable to abstract (hint this is in part due to lacking good macros that could fix this issue.) has issues with making data structures that you have in rust, thus for practical applications people find their naive code is faster. Thus the thread has nothing to do with popularity, often what you are constrained with for projects is 1. what are other poeple using at work 2. Are there libraries to suport some project XYZ. If this gives you lots of freedom a choice like an ML, LISP, or even Forth would be better. ML is intersting as it has been pushing the barrier of what we can do with types (hence linear types showing up in Rust), and region based memory mangement which can serve as an alternative to GC without the same kinds of memory faults you see in C. > Rinse Paul Graham's cum out of your mouth. It seems to me that you are unwilling to discuss what benefits adopting lisp syntax can give you. Namely there is a very strong argument to be made about safety and not shooting yourself in the foot with lisp abstractions as it'll allow you to abstract around foot guns. Some very basic macros which could extend C are safe tagged unions, exhaustion checks to help big codebases stay coherent, some form of ergonomic trivially vectorized looping primitives (much nicer than what you can get with open mp), generation to have C more easily do unsafe tasks without checks in a safe way, etc. > <why are you ignoring the topic??? > <why do you assume I care about the topic??? > You can't have it both ways. It was asked because you think the person you are responding to is OP, which I can't extrapolate via the post style given. >>27066 http://www.inventio.co.uk/threeforthsmakeahole.htm I forgot C is the only correct choice for low memory embeded systems, there is no alternative languages! Further there has never been firmware in Forth or other languages that lack a gc, only C can fulfill those needs in a constrained environment. If you are constrained by a piece of hardware then so be it, however you do know what hardware you are targeting, and if it had support for say forth then forth would be nicer to work with. Takes some work getting used to stack based languages, but it's quite pleasent to use after you get over that hurdle. > So to summarize, there is a reason because A) nobody knows microscheme so who are you going to hire? It's not too hard to hire for what some people consider niche languages. Esp if the language can help you get a lot more done with less, it might be a boon. But that all depends on where you are hiring etc. >>27067 How much extra is the dev time? How much money would you lose if you have a defect in the code? How much is that worth. I'd argue python is also a rather poor choice for that realm, but we do see it so...

>>26621 Can someone tell me where to start with using C language? I finished book, did exercises but just stuck for a week with big headache what actually to DO with it. Halp pls, being imaginaionlet is the worst.

>>27089 There was a C general for that but C users don't feel obligated to make a new one >>>/lambda/19673

>>27090 Sorry, i thought the thread was dead so it won't be a bother to post here. My bad.

>>27091 I mean it is dead because it has hit the bump limit. You can copy and paste that C thread if you care.

>>27092 Yeah, it would be better, don't know why that thread died though. Not many people are using C nowadays or less people started to come here?

>>26647 /thread. Stop blaming the code for you being dogshit at programming and not understanding your code. >>26648 >Memory safety is inane trivia What? That's always been the case with at every level of programming: you have to understand what you're doing at each step of the program. That's why we have fuarrrking comments in the first place: to keep track of the justifications for each line of code. Don't blame the programming language for your bad code. It's like saying it's the programming language's fault for you writing spaghetti code you can't understand: it allows you to do that, but it's 100% your fault.(Lainchan allows you to post irrelevant cartoon images in a programming discussion, but it's 100% your fault if you actually do it.)

>>27111 > /thread. Stop blaming the code for you being dogshit at programming and not understanding your code. fuarrrk off. The reasons don't matter (soykafty programmers or whatever), if avoiding C leads to a statistically observable diminishing of exploitable bugs (it does, entire classes of bugs disappear), then that's what should be done. I haven't written all the code I rely on daily, I certainly didn't rewrite my entire kernel and userspace. > What? That's always been the case with at every level of programming: you have to understand what you're doing at each step of the program. That's why we have fuarrrking comments in the first place: to keep track of the justifications for each line of code. Don't blame the programming language for your bad code. It's like saying it's the programming language's fault for you writing spaghetti code you can't understand: it allows you to do that, but it's 100% your fault. Good job ignoring the obvious point of that post and demonstrating you can't read for soykaf. There is a measurable waste of time spent on non-algorithmic concerns when writing in unsafe languages that has to be accounted. There's a reason it's not popular in businesses other than those where it's the only choice. That lainon has a point. Anything you can have automatically managed which isn't directly relevant to the purpose of your code is inane details. Every check you have to add, every bit of extra management you have to do is time you could be spending on refining your work on a structural and algorithmic level instead. You can write perfectly safe C. It'll also demonstrably take longer than writing safe CL.

>>27111 >What? That's always been the case with at every level of programming: you have to understand what you're doing at each step of the program. I agree with you that a programmer should understand how his program works at every step, but you can understand how something works without repeatably doing the action related to it. I'd compare this fascination with manual memory management with a (hopefully) non-existent fascination with manually optimizing your multiplication calculations in code to reduce the number of cycles needed to process it instead of just letting the compiler do it for you.

>>27112 >if avoiding C leads to a statistically observable diminishing of exploitable bugs (it does, entire classes of bugs disappear) and new (or old) classes of them (re)appear https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/

>>27118 Nice try but no dice. Vendoring idiocy is a thing in C as well, especially for proprietary stuff. Same for bypassing the package manager. Odds are pretty good that any project that uses cmake arbitrarily fetches soykaf over the network to some arbitrary fixed version (that might even be one known vulnerable) even if you have it installed locally and up to date. It's disgusting. All Lisp, Scheme and Python I write are written only with packages fetched by my package manager. I make no assumptions of a maximum version, but I may forbid obsolete versions in some cases.

It looks like the latter part of this thread has descended into the old 'C good / C bad' argument, which on retrospect is understandable. Although efforts have been made to raise good points, they're not new points and I think we're capable of settling much of it and moving on to better topics. Like all arguments that refuse to die, this one's based on a disagreement on semantics: simply put, each camp means a different thing by 'programming'. Some people hold a machine-centered view: programming is telling a machine how to perform a task. Some people hold a task-centered or human-centered view: programming is decomposing a task and expressing how to solve it. From this root disagreement, the more superficial ones follow: languages will be either appropriate or useless, memory management will be your foremost concern or a pointless distraction. Therefore, rather than wasting bandwidth on a flawed proxy argument, people so inclined should tackle the real argument: what does programming mean and why. And when, maybe. The other pillar of the argument is the idea that easy and safe tools breed lazy and careless programmers. The semantic disagreement still applies - if you're from the 'task' camp, you'll want programmers to train hard at algorithms, not bit juggling - however, the idea isn't rooted on it. The claim is intuitive and appealing, and certainly worth discussing. It is the kind of idea that invites speculation, however, and thus care should be taken to back it with factual observations when possible. What does the track record say, after a few decades of programming? What has and hasn't worked, and why, and what can we learn from that? Do watch out for another semantic trap: are we talking about tools for education, or for production? Are the two spheres separate in programming?

>>27127 Some of the original discussions were enlightening, but most of the latter ones are essentially language bashing. My two-cents are that there are reasons to use different languages for different requirements/programs. Extreme example, but I wouldn't use C or Lisp etc. to make a website, and similarly I wouldn't use Go or Java etc. to make a memory allocator

>>26647 >>26859 >>27111 Why use C instead of Assembly? Because it's easier and fast enough that users won't notice the speed loss. Why use C++ instead of C? Because it's easier and fast enough that users won't notice the speed loss. Why use Rust instead of C++? Because it's easier and fast enough that users won't notice the speed loss. Why use Go instead of Rust? Because it's easier and fast enough that users won't notice the speed loss. And so on and so forth. Programming languages are tools to get jobs done. A chainsaw requires more resources than an axe, but it does what it does way quicker.

>>27167 Thanks for the hackneyed contribution.

>>27167 This is just a reiteration of a point made several times earlier, what was even the point of posting this? I'd say it's actually worse than previous iterations because your examples of "easier" languages make absolutely no sense (ex. C++ being easier than C whilst being way more complex of a language and Go being "easier" than Rust even though that's completely arbitrary).

>>27167 why even bother programming at all then? it's not like it actually achieves anything substantial in the real world. programming languages are tools for jobs that don't need to be done

>>27174 I was in a hurry while writing it so the post stinks. Sorry. Point still stands though. >>27175 What are you even saying?

>>27176 it would be easier and faster to not program at all. if your criteria is just to get the "job" done the quickest way possible without regards to quality or self learning then just don't do the job at all.

>>27177 > regards to quality And now we come to the point where we can argue about theoretical soundness vs performance as being indicators or not of performance (GC is one of the easiest way to get such for memory, but hardly the only way).

>>27180 That second performance should be quality

>>27177 For me, the satisfaction of writing code comes from solving a problem. If something is irrelevant to that problem, I feel like I'm wasting time bothering with it. Having to think about memory when writing, for instance, an imageboard package, feels like a waste of time when I know I'm not getting anything of value out of it.

>>26621 I start all my new projects in ANSI C because it's by far: >the fastest language >the most elegant >the one that maps the most elegantly on the hardware >the most portable, because it's so simple that writing compiler for it is a breeze, unlike say pieces of trash like rust or C++ No other languages come close to filling those requirements. >>26628 rust has ten times the number of keywords and bloated features as C, it will eventually die under its own weight like C++. Don't even get me started on that brain dead piece of garbage that is cargo. The problem with all those meme languages that claim to be memory safe, is that they achieve this by restricting the user in many different ways. If you prevent the user from doing stupid things, you'll prevent him from doing clever things and that's precisely why C will always be around, because for every project written in rust, go, haskell or other soy language, there will be at some point a much cleaner, memory-efficient, more clever implementation in C.

>>27276 Of those four greentext criteria, only >the most portable, because it's so simple that writing compiler for it is a breeze, unlike say pieces of trash like rust or C++ is even remotely approaching true.

>>26644 >There are examples of OS being written in Lisp For dedicated CPU architecture >>26647 so much this >>26656 Most Rusters I was exposed to suffer from some sort of brain damage that causes them to ignore pitfalls of Rust's approach to memory managment. Not to mention fans of "Rust in bare metal". That term alone makes that idea sound wrong. >>26903 >Wasn't there some issue where Go didn't have proper exception handling implemented? The only proper way of implementing exception handling is you don't. >>26975 nice delusions

>>27281 They are all true. Cope. >>27167 >Why use C instead of Assembly? Because it abstracts over assembly and make code portable between architecture >Why use C++ instead of C? Because of brain damage, dummies who can't code properly and will fuarrrk up codebase if you don't enforce OOP and black box modules, and who can't code a simple linked list without memory leaks so they have to be spoon fed from the STL. >Why use Rust instead of C++? Because C++ being a magnet for incompetent devs, most C++ projects tend to have massive security flaws that some trannies at mozilla thought they could fix by pushing more restrictions into the language and making it a safe space for retards. >Why use Go instead of Rust? Why use Go at all, enjoy your stop-the-world garbage collection. I mean just use python at this point and just admit you gave up understanding what's going on in your computer.

>>26656 Meanwhile 'C'hads at CEA write nuclear power plant grade code in C99 that they then formally verify with frama-c. https://frama-c.com/

>>27285 owo wats dis https://queue.acm.org/detail.cfm?id=3212479 (Yes that was already posted, but you obviously didn't read it.)

>>27287 not that OP, but nothing written there contradicts that post

>>27288 >>the one that maps the most elegantly on the hardware It doesn't. >>the most portable, because it's so simple that writing compiler for it is a breeze, unlike say pieces of trash like rust or C++ A useful/fast compiler is non-trivial. >>the fastest language Mostly thanks to a lot of effort on its compiler. >>the most elegant Aesthetic consideration, so I'm not addressing it.

>>27289 cont Oh and Fortran can be faster because of better ability to provide hints to the compiler. So not the fastest language.

>>27289 >It doesn't. What was the last time you had problems in that resort?

>>27291 The fact I rarely ever work at quite so low a level with so much care for micro-optimisation doesn't make its non-mapping on the hardware any less true. It does mean the claim that it maps is false though. Which contradicts the other lainon's assertion. Which as far as this conversation goes, is all that matters. In practice, it just means I get to ignore the problem because it doesn't come up in my usage anyway. And also because I trust the compiler to make my code run well on whatever platforms I happen to put it on. But then I don't write C that often. I write wrappers around C more often.

>>27289 >It doesn't. It absolutely does. If you've ever written a driver you would know that you can literally stuff your registers as fields in a properly padded structure and cast the physical memory into that structure and it will just work. All the features C offers were specifically designed to abstract over the memory layout in the most straight-forward yet portable way. This is why all drivers are written in C and always will be. >A useful/fast compiler is non-trivial. Define useful. Also, https://bellard.org/tcc/ >Mostly thanks to a lot of effort on its compiler. Yes and? It's still the fastest one. inb4 in some edge cases Fortran is faster, fair enough. C wasn't designed as a scientific computational language but even then it's faster than pretty much everything else. >Aesthetic consideration, so I'm not addressing it. I would just say that having very few rules yet being very expressive, a paradigm that just makes sense for a computer (separation of data and code), having a tiny almost non existent runtime are pretty objective criteria. >>27290 Ah there you go. Try writing a network driver in fortran lol. Also the restrict keyword in C99 pretty much allows you the same optimisations as what you get in fortran. >>27292 >The fact I rarely ever work at quite so low a level with so much care for micro-optimisation doesn't make its non-mapping on the hardware any less true It's not even about micro optimisations rather than just having a clear understanding of the memory layout, what's dynamically/statically allocated, what the stack looks like and so forth. I have yet to see another language that allows me to have a clear mental picture of what my goddamn memory looks like. >>27287 This article makes it sound like the reason why hardware manufacturers still offer a flat memory/serial machine view on the programmer side is because of le ebil reactionary C programmers and not everyone's sanity and for portability. It's almost blaming C programmers for Spectre and Meltdown kek.From the programmer's perspective you're just dealing with instructions to flush/invalidate the cache. I'm really not sure what's the point of this article.

>>26621 I recently started writing a library in C, so I can use it on both PC and embedded, as well as Android and some other programs I want to support it. C is very much the lingua franca of programming, for better and for worse, and everything supports it to some degree. Alternative languages are spotty at best and may be feature-incomplete on different platoforms or come with significant drawbacks at worst.

>>27287 ahh yes, there it is. everytime i've seen that link posted, it's been painfully obvious that the poster haven't either read it or haven't understood half of it. none of the points in that article stops C from trivially mapping to asm. cache, out of order execution, branch prediction, you don't have direct access to any of those even in asm, trying to spin it it as if it's somehow C's fault is retarded at best and dishonest at worse.

>>27301 > none of the points in that article stops C from trivially mapping to asm. cache, out of order execution, branch prediction, you don't have direct access to any of those even in asm, trying to spin it it as if it's somehow C's fault is retarded at best and dishonest at worse. It's more suggesting that the x86 instruction set is artificially limited to stay with roughly similar semantics. And that people stay with that instruction-set for that reason. >>27294 > I have yet to see another language that allows me to have a clear mental picture of what my goddamn memory looks like. I have yet to see a single language that gives me explicit access to cache. > Yes and? It's still the fastest one Considering that one of the fastest C compilers is LLVM-based, it's probably quite feasible to make languages output to the same IR and piggyback off it. le Rust meme claims to do so, but I haven't verified those claims. > This is why all drivers are written in C and always will be. Some already aren't. Whether that proportion will grow or not is a different question. > Ah there you go. Try writing a network driver in fortran lol. It has the required accesses and can be compiled into a kernel module. Someone even went so far as to do that with Haskell (a non-realtime GC in the kernel is a terrible idea, yes). I don't see what that would prove.

>>27306 correction > It's more suggesting that the x86 instruction set And most other common ones.

>>27306 >It's more suggesting that the x86 instruction set is artificially limited to stay with roughly similar semantics That's the point I disagree the most with in that article. It's like saying GUI development is limited by the fact that screens are flat rectangles and not say spherical. I think there is some value in keeping a standard programmer model across different architectures. >I have yet to see a single language that gives me explicit access to cache. Literally the point of cache is to be hidden from the programmer no ("cache" literally means "hide" in french)? I mean, otherwise yes you could imagine some over-engineered architecture with multi-layer memory and complex pipelines all visible from the programmer interface and create a new language that works well for this but that's like a big middle finger to sanity and portability, imho. In the end, you would have to offer the same Von Neuman type of abstraction to actual programmers who want to get stuff done, so a language that would basically be C and would compile to your optimized, architecture-specific language. Now your language sounds a lot like assembly, right? >Some already aren't. Whether that proportion will grow or not is a different question. And whether it's a good idea is also a different question. So actually --thank you for bringing me to this realisation-- my original point should be more: C is the language that maps the most elegantly to the Von Neumann architecture, which is a de facto standard for most if not all chips/instruction sets and should remain so for everybody's sake and sanity.

Oh yes, the C language programmers balk at using an assembler; what a waste of time. They balk just long enough to stop at the C language; writing in a language that doesn't require that drudgery is just silly. They don't care if the programs work. >>27276 >the fastest language Here's an APL program beating a C language program, because it maps to SIMD and the like well: https://ummaycoc.github.io/wc.apl/ >the most elegant How does anyone believe this? What's elegant about emulating a PDP-11? Learn some real languages. >the one that maps the most elegantly on the hardware Considering modern hardware is emulating a PDP-11, this is almost true. Try looking at other machine designs, but those don't count, right? >the most portable, because it's so simple that writing compiler for it is a breeze The more abstract languages are the most portable. Writing a Forth compiler can be done in less than a kilobyte. The C language makes it far too easy to unintentionally depend on hardware or compiler details. >unlike say pieces of trash like rust or C++ Look at Ada, or its formally-provable subset, SPARK. >>27311 >C is the language that maps the most elegantly to the Von Neumann architecture, which is a de facto standard for most if not all chips/instruction sets and should remain so for everybody's sake and sanity. It doesn't, but that's not the point. Mankind shouldn't use the Von Neumann architecture forever, and then where will that leave most languages? APL will be fine.

>>27313 C wasn't designed specifically for PDP-11, quite the contrary. There is nothing wrong with the von Neumann architecture. The reason why it was de facto so successful is because, unless those clusterfucks of programmer models that you and other lainons seem to want, it's simple enough to be clearly understood and write simple, elegant code on it. >Here's an APL program beating a C language program, because it maps to SIMD and the like well: >looks at this edge case example for a use case C wasn't designed for >also implying there is no way to use SIMD instructions with C >learn a real language >like that soykaf no one ever even heard of Yeah no thank you. I'll keep coding my projects in ANSI C because it fits my needs, even if it's not perfect (but it's still the best one out there). I did a fair bit of Ada and didn't like it one bit, although it's not as bad as C++ or rust.

>>27314 >>also implying there is no way to use SIMD instructions with C Afaik, there is no convenient way to get automatic SIMD transformation by the compiler in C without some sort of explicit hints.

>>27276 >the most elegant Yeah you can write some classes of toy programs and trivial functions very elegantly in it. And then as you crank up the complexity, it becomes harder and harder to avoid ugly, cretinous interfaces with tricky internal behavior. As expected of an abstraction-deficient language. >>27314 >>also implying there is no way to use SIMD instructions with C Pray to the compiler? :​^) Or maybe slyly pepper in a few compiler intrinsics and inline assembly statements? >but muh ANSI C purist cred Don't worry, no one will know (or care) ;​^)

Are there any popular big C projects that never had memory safety bugs, other than OpenBSD?

>>27317 >it becomes harder and harder to avoid ugly, cretinous interfaces with tricky internal behavior That would be because you are a cretin Present Day, Present Time! AHAHAHAHAHA!. Any real programmer doesn't have this problem if he just sit and think on how to do things cleanly. >Don't worry, no one will know (or care) I guess on this room temperature IQ forum you would be right, but thankfully in the real world in industries that matter like nuclear and aeronautics my opinions are prevalent. Go sell your tranny rust language to Airbus engineers who have to formally verify C99 code where everything has to be bounded and statically allocated, on weird custom architectures and let me know how it goes.

This thread really is the /g/ culture containment thread. C zealotry doesn't have a place here, please go back to 4chan.

>>27322 please, keep trolling in the contamination boards like /r/ or /hum/

>>26621 >Cases where it is the best choice? It all comes down to your line of work. If all you develop is user-facing software, higher-level or managed languages and their surrounding ecosystem will serve you just as well, if not better. >Replacements For critical things at kernel level and below, C is ubiquitous. My work is more related to electrical engineering than computing, C and MCU-specific assembly are the norm. Any sensor or peripheral has C libraries to go with it. >Can it be obsoleted Not likely. It will always be relevant in some way, less and less overtime perhaps, but still critical. Too much relies on it for it to be made truly irrelevant.

>>27326 > Not likely. It will always be relevant in some way, less and less overtime perhaps, but still critical. Too much relies on it for it to be made truly irrelevant. COBOL v2 situation?

I've returned to this thread after a while and I am very much disappointed in the "quality" that this thread has dropped down to. The post made by >>27127 still stands true to an ever greater extent, as now people are calling each other names like whining children. I very much hope the moderators of this board delete said whiny posts, or delete the entire thread, as this is a stain on this board which is supposed to be about programming, not whiny bickering. The best example of this behavior is with >>27320, as this user hardly makes any actual arguments and resorts to name calling in most of the post. Notice how the user uses common immature vices like "real programmers $X", "room temperature IQ forum" (literally just calling people here dumb with no explanation), and "tranny rust language" (saying $X is bad via slur with no explanation).

>>27333 I suspect the reason most Rust vs C/C++ threads end up going this way is because they're such vastly different languages. Rust is tuned specifically for high-level programs that need good performance. It'll never quite measure up to C or C++ in terms of raw speed and control of low-level resources, so if that's what you need you might want to use those instead. But it makes up for it with added abstractions and safety features that let it scale up to higher levels easier. You can easily write, for instance, an imageboard engine in Rust, but doing the same thing in C or C++ is a terrible idea.

>>27339 >It'll never quite measure up to C or C++ in terms of raw speed Seems to hold its own in benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html >You can easily write, for instance, an imageboard engine in Rust, but doing the same thing in C or C++ is a terrible idea. How so? Which framework would you use in Rust? And how would it compare to say Drogon for C++?

>>27333 , indeed, OP has formulated a misleading question and no one wanted to actually dissect it. It's easier to invite them to use what they know or try to explain that there exists some higher principles for computer programming. I would say that >>27127 is a start, but I would like to invite them to create a thread where we can question those principles and later OP can project (as in geometry) those principles to whichever programming language they want. Trying to ease OP to move in the right direction I would say >>26621 >Apart from purely recreational, educational or academic purposes, is there any case where beginning a new project in C, C++, etc. is the best choice? If it's what you know, why not? Are you seeing some troubles in using C? Can you fix them? Is it too complicated? If you don't know C, what took you here? It may depend on the project. There might be that higher level project of data where you need some libraries to get started. There will be some high and lows. >Can a memory-managed language that eliminates the kind of security issues that plague C be almost as fast, for all intents and purposes? Yes, there are. Ada, Rust, ... In the end you may even have a cookbook of things to watch out but are you willing to spend time on stuff that's already done? There are many error that can be introduced in C: stack overflow and use-after-free for example. https://matt.sh/howto-c But again, if you spend time looking for those bugs, when will you look at logical bugs or extend your program? But why is C still used? Is it because of the culture? Aside from bugs, memory management is faster if it's done at compilation time. Some languages assert some safety around that using types (and linear logic for Rust as far as I know). >Which languages do you think should (or shouldn't) replace C family languages for various fields (e.g. should OSs prefer a different language to performant graphics code)? I guess there are many interfaces to OpenGL or similar, looks like you want to do something with graphics, but I cannot help you here. Probably you may sketch some graphics in JS using p5.js, but it's a too vague topic. You want a system programming language that does anything. I would like you to restrict you "anything" to a set of objectives you want to achieve instead of tormenting yourself. You may even consider Emacs and call elisp the system programming language. >For those who claim C and C++ aren't obsolete, do you think they ever can be obsoleted? What would be required? Define obsolete. https://spectrum.ieee.org/top-programming-languages/ Following this you may want to start it in python. I would use another metric: take a powerful programming language, for example Scheme. Can you do some features of it in C? Streams? Java did some. Generic programming? C++ has some templates. Combinators? I would hardly made those in C++ following category theory for programmers. And so on. And there could be some other metric that you want to consider, like "speed", but I'm not here for this kind of competitions. Those are futile excuses compared to higher principles. You may have the fastest language and still compute the wrong algorithm on the wrong data structure and be slow. But rereading the title of the thread I see you want one thing. A justification to do not use C: to tell someone you know they shouldn't use it. I think programming is not about religious wars, thus you should ask (yourself first) better questions. And you have some starting point here >>27127 .

>>27362 OP also ignores the fact that C and C++ are very different, and at least C++ is still evolving.

>>27319 No

>>27365 That's a good point to bring up, but technically C also gets some updates, though not to the same degree as C++.

>>27365 >and at least C++ is still evolving. it's evolving like a kid that fell into a barrel of radioactive waste

>>27365 evolving implies it changes for the better. cpp is not that

>>27380 I'd argue a lot of the smarter memory management stuff that came out is exactly that. Improvement.

>>27382 you forget to put that in greentext

>>27382 A lot of interesting memory management, came out of type theory and the ML family of languages. namely Linear/Affine Logic, QTT for even better linear logic, and Region based memory mangement (this is typically used with effect languages, and died early due to the prevalence of GC and the lack of ML types being able to express it easily)

>>27011 >The first version of AVX shipped in 2011 and that is too new to integrate it? Your argument is not convincing. AVX is not vector parallelism; it's just SIMD. >The fallacy is your implication that without C there would be no need for virtual memory. Without C, virtual memory wouldn't be ingrained so deeply in hardware design. Building systems without the virtual memory kludge is going to take decades.

>>27391 >Without C, virtual memory wouldn't be ingrained so deeply in hardware design. How come? >virtual memory kludge It's my observation that virtual memory is a very useful abstraction whilst programming, as having to deal with memory as its actually formatted in computer memory would be very tedious. I'd like to hear your reasoning behind calling it "kludge".

>>27392 >It's my observation that virtual memory is a very useful abstraction whilst programming, as having to deal with memory as its actually formatted in computer memory would be very tedious. I'd like to hear your reasoning behind calling it "kludge". This doesn't make sense. Virtual memory does not provide an easier interface than physical memory. The key benefit of virtual memory is that a programmer, in C or a similar language, can write a program as if it will be run on bare metal. Virtual memory provides the same interface as physical memory. For a long time, even the memory layout was exactly the same for each process. (This is no longer the case. Changing memory addresses frustrate attackers.) The page table, TLB, and loader hide virtual memory indirection from programmers. From a programmer's point of view, virtual memory works exactly like physical memory but with process isolation and paging. >How come? Virtual memory style process isolation is only useful for programs with raw memory access. Virtual memory, however, is only available in userspace: the place that needs raw memory access the least. C requires raw memory access, because of pointers, so userspace support must allow C programs to pretend they have access to the whole machine. The illusion of full machine access, unfortunately, is extremely expensive, so hardware and operating systems must include special support, like page tables and the TLB. This creates a feedback cycle where programmers are encouraged to write programs that rely on virtual memory, which causes hardware manufacturers and operating system developers to prioritize support for virtual memory, and so programmers write even more programs that rely on virtual memory. Worse, complexity is increasing. Even with virtual memory, C programs are very insecure. Special hardware support was added for W^X, but this is only a bandage that frustrates attackers; it doesn't stop them. Other benefits of virtual memory don't apply. Swap is no longer relevant. Using virtual memory to page binaries into memory is not important; there are other ways to load a binary.

>>27395 lmao, hot takes from dunning-kruger posters who have never worked on anything non-trivial are my favourite thing about this board

>>27396 > very assumption and ad-hominem owo very impressive Perhaps if your tooling wasn't soykaf non-trivial work without virtual memory wouldn't svck? Taking your point more seriously from another angle makes it make a lot less sense though. It's a lot easier to secure an OS by only allowing references based on capabilities than presenting direct memory access to other objects.

>>27395 >virtual memory... is extremely expensive you keep saying this but do you have any proof that this is the case? civilian desktop computers nowdays are ridiculous supercomputers software is just so utterly garbage that they seem slow

>>27395 >Virtual memory does not provide an easier interface than physical memory. Virtual memory makes programming linkers, loaders, and sharing between processes much simpler. Linkers, for instance, are simplified because they often take advantage of the uniformity that comes with virtual memory; a Linux linker can exploit the fact that the code segment of a process starts at a specific virtual address IIRC. >The key benefit of virtual memory is that a programmer, in C or a similar language, can write a program as if it will be run on bare metal. That's more a property of virtual memory than a benefit; I think one of the best benefits of virtual memory is the uniform address space. >For a long time, even the memory layout was exactly the same for each process. (This is no longer the case. Changing memory addresses frustrate attackers.) Do you mean the stack? This sounds like you're talking about stack randomization. >Virtual memory style process isolation is only useful for programs with raw memory access. Virtual memory, however, is only available in userspace: the place that needs raw memory access the least. Linkers, loaders, and others would very much disagree with this statement. >unfortunately, is extremely expensive, so hardware and operating systems must include special support, like page tables and the TLB It's my understanding that paging and caching in virtual memory was for efficiency over using main memory. Also, how is it expensive? >Worse, complexity is increasing. Please elaborate on this. >Even with virtual memory, C programs are very insecure. This is true, and it is like kicking dead whales down the beach how much security is overlooked on modern systems, but virtual memory is still a very important security component because of its protection flagging. >Special hardware support was added for W^X, but this is only a bandage that frustrates attackers; it doesn't stop them. This is a very poor argument; just because something doesn't completely stop the attacker doesn't mean it's worthless. W^X protection is a key component of a secure system. Of course, it has to be paired with many things as well if one is attempting to make a secure system.

>>27395 So riddle me this, why did Lisp machines, which were designed to run a very high-level language, use virtual memory? Maybe it's because it's a good and useful thing to have, even for high-level languages, and you're a moron. Speaking of Lisp machines, I wish modern computers had support for hardware-assisted GC on top of virtual memory.

even in a locked down system that refuses to let you use pointers, virtual memory segmentation is still useful for stopping hardware bit-flips enabling user level programs to overwrite the os and other programs. inexplicible segfault from a bit flip is way better than inexplicable memory corruption. >>27499 you can do tagged pointers in software, so you really only need os level support. nobody cared enough to actually do anything like that in "modern" oses though.

>>27498 By default on Debian and Ubuntu, GCC generates Position Independent Executables. (I'd guess most modern systems and compilers are this way.) Code segments are started at random addresses; the initial instruction pointer is randomized. Compiling a program with PIE explicitly disabled and running it in GDB with randomization enabled: $ gcc -no-pie -o test.out test.c $ gdb test.out (gdb) set disable-randomization off (gdb) start Temporary breakpoint 1 at 0x4004fa Starting program: ~/test.out Temporary breakpoint 1, 0x00000000004004fa in main () (gdb) i r rip rip 0x4004fa0x4004fa <main+4> (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y Temporary breakpoint 2 at 0x4004fa Starting program: ~/test.out Temporary breakpoint 2, 0x00000000004004fa in main () (gdb) i r rip rip 0x4004fa0x4004fa <main+4> (gdb) quit For each run, the initial address is the same. Compiling a program with default options and running it in GDB with randomization enabled: $ gcc -o test.out test.c $ gdb test.out (gdb) set disable-randomization off (gdb) start Temporary breakpoint 1 at 0x6b4 Starting program: ~/test.out Temporary breakpoint 1, 0x000055aaa396a6b4 in main () (gdb) i r rip rip 0x55aaa396a6b40x55aaa396a6b4 <main+4> (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y Temporary breakpoint 2 at 0x55aaa396a6b4 Starting program: ~/test.out Temporary breakpoint 2, 0x000055684b5a66b4 in main () (gdb) i r rip rip 0x55684b5a66b40x55684b5a66b4 <main+4> (gdb) quit For each run, the initial address is randomized. >That's more a property of virtual memory than a benefit; I think one of the best benefits of virtual memory is the uniform address space. Yes, I think, that's what I meant to say. >It's my understanding that paging and caching in virtual memory was for efficiency over using main memory. Also, how is it expensive? The amount of RAM on modern systems has made paging useless for all but the cheapest machines. Virtual memory adds a level of indirection that slows software down. This is why the TLB exists, but there are still misses. If your cache (swap) doesn't make anything faster, but it requires another cache (TLB) to work, then your system is not going to be any faster. Worse, virtual memory greatly complicates hardware and OS development. Man hours wasted. >Please elaborate on this. Historically, complexity has increased. On a modern Intel 64 processor, for example, "There is no mode bit to disable segmentation." Segmentation and paging is used for all addressing. In fairness, segmentation is not virtual memory, but it aims to accomplish process isolation in a comparable way; paging is a more sophisticated version of segmentation. As paging grows more complicated and exposes more options, more bits and page table options become available and the supporting hardware for paging increases in complexity. "Do you want 3 or 4 level paging with that?" Operating systems must keep of with these new additions.

>>27509 >virtual memory segmentation is still useful for stopping hardware bit-flips enabling user level programs to overwrite the os and other programs. >inexplicible segfault from a bit flip is way better than inexplicable memory corruption. If you're referring to rowhammer and the like, Intel is to blame. ECC memory is part of the actual answer to that problem, not software. Software solutions will essentially be nothing more than patching over a gaping hole and hoping nothing touches it again, because the fundamental problem is broken and inadequate hardware. If you want that to not be a problem, fix the hardware.

>>27510 Thanks for clarifying you were speaking about PIC/PIE; I was under the assumption you were talking about the stack. >The amount of RAM on modern systems has made paging useless for all but the cheapest machines. I would say I have a pretty modern computer, and I definitely wouldn't say it's of that "cheapest machines" category you referred to. My collective DRAM is multitudes of times larger than my collective SRAM, being well over 500 times larger.

>>27514 >My collective DRAM is multitudes of times larger than my collective SRAM, being well over 500 times larger. Yes, but that's not paging. The caching of DRAM to SRAM doesn't require virtual memory either.

>>27523 >Yes, but that's not paging. I'd say DRAM and SRAM are very much related to paging. >The caching of DRAM to SRAM doesn't require virtual memory either. I never stated this. The original claim I was responding stated that paging as a whole was useless on modern machines. Assuming I misunderstood the original claim and it was actually specifically talking about virtual memory paging, then I'd like to ask why virtual memory paging in particular is "useless on modern machines".

>>27395 >Virtual memory style process isolation is only useful for programs with raw memory access. Even if you don't see the pointers your interpreter still needs to allocate memory somehow. What are you going to do, make a systemcall to the kernel for everything 10 byte object you want to create? >Swap is no longer relevant. How do you think hibernate works? >>27527 >why virtual memory paging in particular is "useless on modern machines". Because everyone has 8GB of RAM and Facebook only takes 1GB of RAM. >>27397 >Perhaps if your tooling wasn't soykaf non-trivial work without virtual memory wouldn't svck? >your Why are you so tribal? Somehow you've convinced yourself that C is evil and virtual memory has something to do with C so that is evil too and anyone who disagrees with me must be a C programmer and is also evil. You're obviously intelligent enough to read up on this stuff (although >>27396 is right you've read a lot but obviously never written your own compiler or actually ''used'' C in any serious low level way). I don't understand how your brain has been so thoroughly hijacked with all this religious zealotry.

How can a basic, elegant assembly abstraction be obsolete? Are there any other no-nonsense assembly abstractions out there?

>>27527 >I'd say DRAM and SRAM are very much related to paging. Together, they're very much related to caching, not paging. Unless there's something I don't know; you could bring it up. >>27528 >How do you think hibernate works? By dumping RAM into a hard drive. This is probably easy to implement with paging, but it's not something that requires virtual memory and it doesn't concern me. I didn't bring it up; I've never felt hibernation was useful. YMMV >Even if you don't see the pointers your interpreter still needs to allocate memory somehow. What are you going to do, make a systemcall to the kernel for everything 10 byte object you want to create? No. You don't need a systemcall for every 10 byte object you create the same way you don't need a systemcall for every malloc call on current systems. I don't see the issue. >>27529 Some people swear by assembler macros, but that seems a little too low level.

>>26621 >Apart from purely recreational, educational or academic purposes, is there any case where beginning a new project in C, C++, etc. is the best choice? Embedded systems.

>>27534 >Together, they're very much related to caching, not paging. Paging is a unit of management for caching. https://wikiless.org/wiki/Memory_paging

>>27539 ? what most cache entries are 32 bytes long.

>>27539 It's called *paging* because there's a *page* table. Your SRAM caches do not have a page table. https://wikiless.org/wiki/CPU_cache All memory paging is caching; only some caching is memory paging.

>>27534 >This is probably easy to implement with paging, but it's not something that requires virtual memory >Swap is no longer relevant. Not sure if you're trying to rewrite history or just pathetically confused. >No. You don't need a systemcall for every 10 byte object you create the same way you don't need a systemcall for every malloc call on current systems Virtual memory allows the process to use whatever memory address it wants and the kernel ensures that the mapping to real memory does not clash with another process. If you want to get rid of virtual memory then every process needs to somehow coordinate with every other process to ensure the same memory location is not used twice. >I don't see the issue. Because you don't know what you're talking about.

>>27547 >Virtual memory allows the process to use whatever memory address it wants and the kernel ensures that the mapping to real memory does not clash with another process. With virtual memory, user processes do not use whatever memory address they want, they pretend to. There is no need for this. Virtual memory is not the only way to coordinate memory access. Virtual memory is not the only way to enforce process isolation. Managed operating systems cannot access arbitrary memory addresses except in kernel space, but they don't need virtual memory to coordinate memory access or enforce process isolation. Virtual memory made segment descriptor style process isolation obsolete. Managed operating systems will make virtual memory obsolete. The big questions are: how long will programmers and hardware designers have to wait for this to happen; how much legacy support will programmers and hardware designers have to deal with after this happens?

>>27547 >Not sure if you're trying to rewrite history or just pathetically confused. Not sure if you're deliberately assuming the most meaningless pronoun antecedent to troll or just pathetically angry.

>>27551 >Managed operating systems cannot access arbitrary memory addresses except in kernel space, but they don't need virtual memory to coordinate memory access or enforce process isolation. And you don't need gasoline to move airplanes. Baseless assertion is not an argument. >>27552 Do you admit that you are wrong about swap is "useless". Or are you hoping to brush past it with ad hominem.

>>27567 airplanes use the energy in the air to fly with their turbines. that's why turbulence is a thing, the turbines can't process the violent air. airplanes don't use fuel.

>>27568 Why are you trying to argue against a sarcastic strawman? It was a prompt for you to elaborate on your own fuarrrking statements about virtual memory.

>>26621 > is there any case where beginning a new project in C, C++, etc. is the best choice? Microcontrollers... especially when you have to target many of them at once. Some don't even have C++ compilers. Writing portable C code is especially useful in that case. The only thing you have to usually rewrite is the PAL if your code is otherwise portable. A few years ago I had to target STM8 using the Cosmic C Compiler which does not even have full C99 compatibility; for one it does not allow arrays of bools.

>>27569 Throughout the thread, reasons why virtual memory is used have been specified: process isolation; uniform memory layout, paging, protection from rowhammer style attacks, hibernation. Arguments explaining why those reasons aren't relevant have been given. Uniform memory layout, for example, is no longer relevant when every executable is a PIE running with ASLR. This is an interesting technical discussion. The fact that a system level interpreter, something that's already been heavily researched and implemented multiple times, exists raises the question "Why bother with virtual memory at all on a system that needs a kernel module to use pointers?" Managed operating systems, system level interpreters, are an interesting alternative that doesn't seem to require virtual memory at all. >Why are you trying to argue against a sarcastic strawman? It was a prompt for you to elaborate on your own fuarrrking statements about virtual memory. Why are you so mad? If someone spouts lines like, "And you don't need gasoline to move airplanes. Baseless assertion is not an argument.", what possible answer is there besides silence or an insult? He or she could have just looked up managed operating systems on their own or even just asked directly, but he or she took a cheap jab instead. Why? Maybe they're embarrassed to admit they don't know what a managed operating system is? Probably not. Either way, they clearly don't want to have a technical discussion.

>>27571 >for one it does not allow arrays of bools. That's really weird. It had a bool typedef but you couldn't declare an array of bools?

>>27574 >Why are you so mad? >Throughout the thread, reasons why .... blah blah blah Not good enough. You said >Managed operating systems cannot access arbitrary memory addresses except in kernel space, but they don't need virtual memory to coordinate memory access or enforce process isolation. Elaborate on your opinions rather than just spilling the soykaf.

You don't need virtual memory for process isolation in a managed operating system because all code is run through a kernel level bytecode interpreter. In a managed operating system, only the kernel and kernel modules can use pointers. In practice, the operating system is just one giant program running in the full memory space and processes are really just threads running within that giant program. If each program had access to pointers, this would be extremely dangerous, but on a managed operating system, userspace programs have no access to raw pointers. This is analogous to how sharing physical memory isn't dangerous in a system with virtual memory. In an operating system with virtual memory, only the kernel and kernel modules can use physical addresses directly. Userspace programs are restricted to logical/virtual addresses. In a managed operating systems, only the kernel and kernel modules can use pointers. Userspace programs cannot use physical or logical/virtual addresses. This makes virtual memory redundant for task isolation.

>>27585 >In practice, the operating system is just one giant program running in the full memory space and processes are really just threads running within that giant program. In practice there's one heap and one garbage collector for everything on the system and you don't think that will affect performance or prevent you using multiple CPU cores? Everytime you allocate a new 10 byte object you need to stop everything to access the global memory manager and get a 10byte slice of real memory? And when you run out of memory what do you do, just kill the offending "thread"? I guess we already established that you personally don't use hibernation so fuarrrk everyone else. Yeah I don't know dude. If you remember you are supposed to be arguing that this approach is somehow better, not just that it's technically possible if you close your eyes and try heard enough.

>>27585 Preach, dude. You're absolutely right. Memory safety is the future, and virtual memory is obsolete, now that we have memory-safe languages (that is to say, they were obsolete 30 years ago). The same goes for microkernels: http://catern.com/microkernels.html >>27595 None of that has to be true, think a little more creatively. You can have a per-CPU or per-software-process heap and GC, like Singularity did.

You should really read and understand https://queue.acm.org/detail.cfm?id=3212479 before speaking about this. It was already linked, but I think the article makes it really clear how we've contorted our architectures to meet the goal of "Make existing C code run fast". The article doesn't explicitly talk about how virtual memory is unnecessary, but the same kinds of arguments apply.

>>27551 >Virtual memory made segment descriptor style process isolation obsolete. Actually I feel like this was kind of a mistake, not an improvement. Segmentation was complicated, but it was a kind of complication that systems need to deal with: Localized resources, that can only be accessed in certain circumstances/conditions, are extremely important in many applications; for example, distributed programming and NUMA (but I repeat myself). Virtual memory gave us flat addressing instead of segmented addressing, but really the only reason that was better was because C is deficient! A really powerful modern language that replaces C would have a modal type system ala http://www.cs.cmu.edu/~tom7/papers/modal-types-for-mobile-code.pdf which would be able to handle segmentation, and distributed programming, and NUMA, easily. Your posts are against C and caches and flat address spaces so I assume you also appreciate the value of programming models which can easily handle multiple address spaces.

>>27623 >You can have a per-CPU heap and GC Then you don't have SMP, you just have two computers sharing the same silicon. >or per-software-process Elaborate how this solves the problems mentioned. If there is no virtual memory and MMU ,and now you're saying there's also no centralized heap, then how do you prevent "processes" from clobbering each other's memory. >>27625 >i can't explain it but read the same thing that convinced me and maybe it will convince you too Doubtful. >>27626 >the only reason that was better was because C is deficient! Just repeating the same thing over and over doesn't make it true. Elaborate on your opinions rather than just spilling the soykaf.

>>27627 >Then you don't have SMP, you just have two computers sharing the same silicon. SMP is bad too :) But that's a further discussion >Elaborate how this solves the problems mentioned. If there is no virtual memory and MMU ,and now you're saying there's also no centralized heap, then how do you prevent "processes" from clobbering each other's memory. You have a hierarchy of memory managers, just like on Unix. There's a central manager handing out pages, and each process manages its own allocation in the pages it requests from that central manager. Again, pretty obvious: That's how it works today, so it's obvious you would do that without virtual memory too.

>>27625 >You should really read and understand https://queue.acm.org/detail.cfm?id=3212479 Despite the authors best attempts at making it seem like C is somehow completely out of touch with the hardware, the only thing that article actually accomplishes is demonstarting how complex a modern cpu is, nothing more. The implementation of the same instruction set being different is not a new thing. And the points about not having direct access to cache, out of process execution etc applies to ALL languages (even asm) not just C. So if you think that article is an argument against C then you should take your own advice.

>>27628 >There's a central manager handing out pages, and each process manages its own allocation in the pages it requests from that central manager. >it's obvious you would do that without virtual memory too. The difference is with virtual memory the OS doesn't need to actually allocate every page it gives to a process until it is written. Additionally when two processes need the same data, the OS can map their virtual addresses to the same physical RAM. And when one process does a write the OS can then remap what those virtual addresses point to behind the scenes. So virtual memory makes RAM usage much more efficient where the same library is loaded by multiple processes or the same file is opened by multiple processes. Without virtual memory you cannot do any of this remapping. You need to give every process its own dedicated memory from the start. So in addition to wasting a lot of RAM that also means you can't write a page that hasn't been used for a while to disk and reassign that RAM to another process. So when a process asks for 2GB of RAM that's 2GB of RAM no one else can use while that process is running. >pretty obvious The only thing that's obvious is that you haven't thought this through. >SMP is bad too :) Which is it? You can do SMP without virtual memory or SMP is bad anyway.

>SMP bad in what sense of meaning and functionality or design?

>>27630 >The difference is with virtual memory the OS doesn't need to actually allocate every page it gives to a process until it is written. The resulting memory overcommit is generally considered a flaw of Unix/Linux systems. But even if it wasn't: You could still do lazy allocation. Just use tombstones or futures or any of a million different mechanisms for laziness. >Additionally when two processes need the same data, the OS can map their virtual addresses to the same physical RAM. That's not useful for implementing malloc. But anyway, just give the two processes the same physical addresses. >And when one process does a write the OS can then remap what those virtual addresses point to behind the scenes That's not useful for implementing malloc, and like I said above, you could do that with physical addresses with tombstones or thunks or many different techniques. >So virtual memory makes RAM usage much more efficient where the same library is loaded by multiple processes or the same file is opened by multiple processes. Again, physical memory can achieve that too: When a file is loaded a second time, just return the same physical address as the first time. >Without virtual memory you cannot do any of this remapping. You need to give every process its own dedicated memory from the start. So in addition to wasting a lot of RAM that also means you can't write a page that hasn't been used for a while to disk and reassign that RAM to another process. So when a process asks for 2GB of RAM that's 2GB of RAM no one else can use while that process is running. Besides the fact that this is misguided, it's also just historically flat-out wrong. Paging and virtual memory have nothing to do with each other. Unix from the very start had paging, and PDP-7s do not have virtual memory. If you want to know how that works, look it up. >Which is it? You can do SMP without virtual memory or SMP is bad anyway. Both >>27633 SMP is bad because it's not real. Early on there were processors which really were symmetric, and so the whole SMP abstraction (every thread can access all data in memory with the same costs, threads can be freely migrated between CPUs, every CPU can run any thread, etc) was a decent way to approach programming on those processors. But modern computers are nothing like SMP: Large amounts of computation happens on coprocessors (GPUs, for example), and even "CPUs" are heavily NUMA'd and require lots of thinking about physical locality to get maximum performance.

>>27634 Yeah, a lot of what virtual memory provides is just general caching concepts. If a page is read only, you can reuse the page without copying the entire page. If a super duper read only managed operating system memory blob is read only, you can reuse the reference without copying the memory blob. >Paging and virtual memory have nothing to do with each other. That's a strong statement. Virtual memory makes paging easy and paging and virtual memory are closely coupled. They're coupled in implementations and explanations. I'm sure you can implement paging without virtual memory, maybe something like AllegroCache (https://franz.com/products/allegrocache/), but I couldn't say paging and virtual memory have nothing to do with each other.

>>27628 >You have a hierarchy of memory managers, just like on Unix. There's a central manager handing out pages, and each process manages its own allocation in the pages it requests from that central manager. Again, pretty obvious: That's how it works today, so it's obvious you would do that without virtual memory too. Racket's custodians are a good match for this. In Racket, each thread has a custodian that holds on to file handles and ports. When the thread dies, the custodian closes them. Custodians can also set memory requirements and limits. If a thread, for example, can't be allocated enough memory, it can't be started. If a thread uses too much memory, it will kill itself. It's cool stuff. DrRacket, the official IDE, uses custodians to detect runaway processes. If your REPL uses too much memory, DrRacket will ask if you want to kill the process or increase the memory limit. An extension that includes IO access, security levels, and such would be a nice alternative to processes. The current implementation, of course, can't run on bare hardware. Maybe someday.

>>27626 >Actually I feel like this was kind of a mistake, not an improvement. I've never heard anyone suggest that before. How would segmentation help with NUMA? Would it keep processors from invalidating each other's caches at the hardware level? In other words, force SMP to not share memory? >300+ page modal type systems dissertation Maybe later.

>>27641 >I've never heard anyone suggest that before. How would segmentation help with NUMA? Would it keep processors from invalidating each other's caches at the hardware level? In other words, force SMP to not share memory? It's not that segmentation would help with NUMA, but that the problems are similar in many ways. e.g., pointers to the same memory area (near pointers) are cheaper to use; pointers to a different memory area (far pointers) are more expensive; if you keep track of where things are located, memory access is cheaper (that is, you can use near pointers which are more memory-efficient), but you also can just ignore the whole issue and forget about where things are located (that is, you can just use far pointers all the time).

>>27634 >memory overcommit is generally considered a flaw of Unix/Linux systems. Explain what you think is different about Windows exactly. >Just use tombstones Explain how the tombstones concept means you don't need to copy a shared library into two different process address spaces. >any of a million different mechanisms for laziness. Name one. >just give the two processes the same physical addresses You can't do that because one process may change the data or use the memory address for something else. You've effectively destroyed process isolation by doing this. >PDP-7s do not have virtual memory Virtual memory is an operating system concept.

>>27657 >Explain what you think is different about Windows exactly Windows doesn't have overcommit, try googling before you ask stupid questions. >>any of a million different mechanisms for laziness. >Name one. Thunks. Read SICP. >You can't do that because one process may change the data or use the memory address for something else. You've effectively destroyed process isolation by doing this. Have you heard of "const"? It is a feature of the C language which allows you to mark a pointer as read only. Of course, C is memory unsafe, which means you can easily bypass it. But in a memory safe language, it can't be bypassed.

>>27658 >Windows doesn't have overcommit Wrong. https://superuser.com/questions/1194263/will-microsoft-windows-10-overcommit-memory/1228040#1228040 >Read SICP. I have. Copy and paste one example from the book that applies to this discussion. >Of course, C is memory unsafe, which means you can easily bypass it. Cost in C is a compile time feature that's why you can bypass it at runtime. >in a memory safe language, it can't be bypassed That depends on the implementation and has nothing to do with the argument you are responding to. When a process, written in any language, opens a file or asks for memory it indicates to the kernel its intent to read or write to it. Without virtual memory the OS needs to copy all data that could be written before giving the memory, which is very wasteful because the process could end up writing only a single byte or nothing at all.

>>27659 >>in a memory safe language, it can't be bypassed >That depends on the implementation and has nothing to do with the argument you are responding to. The entire point of this argument is that you don't need virtual memory if your entire system is one big memory-safe language runtime

>>27660 >The entire point of this argument is that you don't need virtual memory if your entire system is one big memory-safe language runtime But then you acknowledged that having a single heap for everything would be stupidly slow and insecure so each "processes" will manage its own pages ( >>27628 ). But now you're wasting RAM when two "processes" read the same data and you've lost the ability to swap to disk. So now what? You keep moving the goal posts around depending on the latest argument you're trying to defend against as if nobody will notice you've contradicted yourself 50 times already.

>>27661 >But then you acknowledged that having a single heap for everything would be stupidly slow and insecure so each "processes" will manage its own pages Yes, each process in the single language runtime can have its own heap. Where's the contradiction?

>>27657 >You can't do that because one process may change the data or use the memory address for something else. You've effectively destroyed process isolation by doing this. No, in a managed OS a process can't do any of that.

all this argumentation is pretty absurd, because this "managed os" doesn't exist yet, as while developing such as system, even if you eschew virtual memory, having memory protection to detect memory access violations (segfaults) would be very useful. built in asserts in the hardware. after its done, then you could move it to hardware without virtual memory, but while developing it, it would be very useful to have that error detection.

>>27670 I'm not involved with that conversation but... >because this "managed os" doesn't exist yet, PhantomOS exists. It's definitely not stable yet, but it exists.

>>27670 >all this argumentation is pretty absurd, because this "managed os" doesn't exist yet There's at least three: Singularity, PhantomOS, Inferno(?).

>>27665 Is there any way to learn more about the concept of managed operating systems? I think yours is a compelling argument in their favor.

>>26661 the Oberon OS did use some C, but iirc not much for it to be worth arguing against Oberon.

>>27673 IIRC it's an operating system that does everything in a VM with high-level features like garbage collection and memory safety. This gives you better security and portability, but at the cost of performance.

>>27688 >This gives you better security and portability, but at the cost of performance. >but at the cost of performance. No. A managed OS in running all processes in ring-0 without virtual memory outperformed. Aiken demonstrated this in the 2006 paper Deconstructing Process Isolation. The graph in the picture shows the performance of Singularity with different levels of hardware protection. For each task, the left most vertical bar shows no hardware isolation: no virtual memory or user mode and kernel mode separation. As the bars move to the right, more hardware support is added. For each task, the right most vertical shows full hardware isolation for each process: each process has virtual memory enforced process isolation and require a user mode to kernel mode context switch to run system calls. Results: >Without hardware protection, system calls and inter-process communication run significantly faster (30–500%) and a communication-intensive benchmark runs approximately 20% faster. >Changing address spaces incurred minor costs for micro-benchmarks, but was a significant overhead for a macro-benchmark with a large amount of communications and context switching. In addition, hardware protection increased the cost and complexity of inter-process communication.

>>27673 You'll probably have to read papers and project pages. There's always source code. If you find a good book, please post it.

>>26647 unfortunately, you might be not the only programmer working on something. not every programmer is good, so some rules should be enforced. and if a computer does a lot of tedious jobs instead of a programmer (and memory management is tedious, let's agree on that), then more programmers' brain resources can be used to build something great

>>26656 At least you can isolate unsafe blocks of code for easier problem detection

>>27698 how many syscalls do you really need though? even if syscalls are faster, most computing time is not spent on syscalls. it's slowing down the whole program to speed up a small part of it. even if there's now no difference between a syscall and a regular call, from a perf standpoint it's not worth it. whole perf discussion is pretty moot tho, seeing as how insanely slow javascript and java have become the standard way of programming things now though. your managed os idea if done properly would be an improvement for most software. but i hate the idea of locked down "managed oses" that only give you indirect access to the hardware, and constrain the ways you can do things. it's really difficult to peer past all the cruft and garbage these days and see how things actually work, and moreso to build closer to the foundation, but its technically possible. managed os without jailbreaking you'd be stuck there. not that having managed oses alongside regular ones would be a problem, but having them mandated for muh "cyber security" and "terrorism" sounds not so far fetched these days.

>>27719 >even if syscalls are faster, most computing time is not spent on syscalls. it really depends on what you're doing. For instance I/O-heavy applications will spend a significant fraction of their time in syscalls (if they're written well). For big number-crunching programs it doesn't really matter, in that case you'll usually be relying on specialty hardware to get good performance.

>>27719 >not that having managed oses alongside regular ones would be a problem, but having them mandated for muh "cyber security" and "terrorism" sounds not so far fetched these days. That just means you'd be working in their equivalent of kernel-space with modules that upstream might refuse to integrate. You'd still have access at least as long as it's FOSS, and only idiots would accept anything less.

>>27721 >That just means you'd be working in their equivalent of kernel-space with modules that upstream might refuse to integrate. You'd still have access at least as long as it's FOSS, and only idiots would accept anything less. This is an impressively advanced and accurate take for Lain. It's like I'm reading something from an alternate universe where instead of OS hobbyists all being enthused about Plan 9, they're enthused about some managed OS. (Not that Plan 9 isn't good, I just wish there was a managed OS that was accessible to hobbyists)

>>27719 >how many syscalls do you really need though? The same paper benchmarks a compiler and web application. Removing hardware based process isolation improved performance for both. >>27741 >I just wish there was a managed OS that was accessible to hobbyists Isn't Inferno sort of that?

>is there any case where beginning a new project in C, C++, etc. is the best choice? OSs. Libraries that perform a lot of big arithmetic operations of some kind. Any scenario where performance matters a lot (which are not many nowadays i belive). That's about it, I think.

>>27742 I'm surprised inferno didn't catch on more. It's an amazing operating system.

>>26621 > is there any case where beginning a new project in C, many embedded projects where MicroPython still isn't feasible >C++, automotive, aerospace, embedded, gamedev, graphics, audio, simulation, robotics, HPC etc. is the best choice?

>>27765 >many embedded projects where MicroPython still isn't feasible Does anyone even like MicroPython?

>Is the C family finally obsolete? No, and it probably never will be. As a language that: >A) Has been around for many decades >B) Is used in a diverse range of applications, many of them important such as Operating Systems and Embedded devices >C) Is one of the best in performance, size, and flexibility It will not disappear. The ecosystem is quite mature and today massive applications it is still used in are things like the API Vulkan, which is written in pure C99 with around an equal amount of support for C++ and a little support from Rust (Community-based and not supported by Khronos unlike C and C++). C is "unsafe" by default. It is a language that leaves a lot up to the developer in return for high performance and low-level functionality. Its perfect for writing things like drivers, operating systems, and sensitive applications. Something like Rust is already way too big to be used majorly in something like the Linux Kernel, and its compiler is left in the dust by those from C++ and especially C.

> Is the C family finally obsolete? No, C is a method of manipulating computer hardware, I don't see what new programming languages have to do with that?

>>27794 >and its compiler is left in the dust by those from C++ and especially C. I'm admittedly kind of new to Rust, having used it for less than a year, but going off of both personal observation and looking at benchmarks, it seems to be about as fast as C++, and in some cases actually faster. >C is "unsafe" by default I don't know why this is a good thing. You can still do dangerous stuff in Rust, you just have to explicitly opt into it. This is, IMO, way better than the C approach, where everything is broken by default.

>>27795 New languages may have the same capabilities as C while not being as horrible. See Zig, Rust, etc.

>>27811 Zig - a meme language without barely any documentation Rust - a language with one of the ugliest syntax I've ever seen (also prepare to write [unsafe] block's everywhere for even basic manipulations with simple types such as pointers and references. This completely breaks the point of Rust, and make it the same in terms of safety as C++) C and C++ won't be replaced, because both are standarts in the programming (C - drivers and other low-level stuff. C++ gamedev)

>>27820 Attachment unrelated

>>27820 Zig is literally one of the least blub languages right after Rust though. C++ is such a bad language it makes you want to vomit after coding in it a bit. You sound like a blublanger btw.

https://ziglang.org/learn/samples The syntax looks niggerlicious desu...

>>27820 https://ziglang.org/documentation/master/ is pretty extensive, and https://ziglearn.org/chapter-2/ has a lot of documentation on common patterns. It helped me a lot. >>27824 The syntax is fine, but where it really shines is the comptime feature. I'm currently writing a small library in Zig that depend heavily on function signature and it's a breeze. It would have been hell trying to write it with C++ templates.

>>27820 >also prepare to write [unsafe] block's everywhere for even basic manipulations with simple types such as pointers and references. This completely breaks the point of Rust, and make it the same in terms of safety as C++ The point of Rust isn't to be safe, it's to be safe by default. Having dangerous features but making them opt-in makes stupid mistakes less likely without sacrificing the language's power or flexibility.

C isn't a bad language, but it is not forgiving to bad programmers. Its great for writing drivers, operating systems, and other performance-intensive, low-level software. A memory-safe-by-default language should be fine for the other C things. I don't like Rust nor its ecosystem, but I like the idea of safety measures for soykafty programmers (because lets face it, if everyone was using C, everything would be buggy, insecure, and unreliable. There are A LOT of soykafty programmers, and if I was a company executive, I'd want my employees using languages that hold their hands)

>>27829 You act as if "good programmers" are perfect and failure-proof. They're human too.

This is the worst thread on Lainchan right now. It's just a flamewar where nobody's going to win due to one of the sides being C/UNIX zealots whose minds cannot be changed. This is /g/ levels of discussion. Please let this thread die already.

>>27835 OP here, I stopped posting at >>26629 and reading at >>26656

>>27835 >Please let this thread die already. Meanwhile you bumped the thread. Put "sage" into your email field next time, if you really want a thread to die.

>>27835 Implying 90% of the threads aren't just like this one.

>>27719 >managed os without jailbreaking you'd be stuck there. A managed OS is not inherently opaque. At least, it's not any more opaque than any current OS. If your processor only boots hardware manufacturer signed kernels, you can't load kernel modules, and you can't ever use a physical memory address, you're locked out. It doesn't matter why you can't use a physical memory address. It could be because userspace is stuck with virtual memory addresses, like most operating systems today, or it could be that userspace can't use any kind of memory address, physical or virtual. Either way, you're locked out. This is why modern phones have to be jail broken despite not using a managed OS. The choice between managed and not managed is orthogonal to whether a system is locked down. Maybe. I guess a managed OS would be less likely to have an exploit for jail breaking? >>27835 People who cry about religion are the worst posters, bar none. You are what you focus on.

C and C++ are the blubbiest languages around. They should be done in like the Lisps - swept into the dustbin of history! GoLang is here to save us all, baby!

>>27828 I agree with your point, that Rust is safer language by default. But in my opinion every language is safe, if the code is written by a competent programmer. >But people can make mistakes True, but I'm sure, that most programming languages have some kind of protection against this. For example GCC has "--Wall" argument, that will point to the problematic places in your code.

>>27852 Rust is a -- half/blub language. It's less blubby than C or C++ but still fairly blub when compared to Haskal. All in all I'd say I'd use it if it were an employable language.

>>27848 its funny you mention go, because go code tends to represent a kind of regression to C-like design patterns that modern languages have done away with using stuff like traits and generics. like in order to do polymorphism in go you have to do the C thing where you compose a struct inside a struct and give it a vtable and all that.

>>27852 >every language is safe, if the code is written by a competent programmer im not sure this statement is as meaningful as you think it is. >every car is safe if you dont crash it >every poison is safe if you dont drink it >every explosive is safe if you are outside its blast radius this is of course completely true, but what information does it give us? what does "safety" even mean in this context where everything is equally safe?

>>27857 idk what a vtable is. Sounds like blub.

>>27859 i dont know what blub is. a vtable is how you dynamically dispatch functions.

>>27861 what? You don't know what blub is? God now I know what's going on here. You're thinking in blub.

>>27864 Can you spare us the schizo talk and actually explain yourself instead? t. another lainon

>>27865 As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. Languages exist on a scale of blub to nonblub. I don't use blub languages.

>>27865 lisp programmers are smug and think they found the most advanced language ever, so they call people that like other languages blub programmers. blub being a mediocore programmer that doesn't understand the greatness of lisp, and instead sees lisp's greatness as a flaw. dunning kruger for programming languages. http://wiki.c2.com/?BlubParadox the problem with all this, and this thread though, is that anything anyone likes about a language is dismissed, in favor of trying to drive the point in of why x language is fundamentally superior because it has this or that. people are talking past eachother because they're trying to prove or defend a point, not learn or achieve something.

>>27866 the problem is though, the blub sees other languages as blub. how do you know you're not actually a blub? isn't the only measure what you've actually achieved by programming?

>>27866 im not sure how that relates to what i said. i just noted that the design patterns people use to do polymorphism in Go have some resemblance to the design patterns people have historically used to do the same thing in C. they arent particularly similar beyond that, i just thought the resemblance in this one aspect was ironic. im not sure i even buy the premise here, but wouldnt the "blub programmer" consider these languages good enough, and disregard the more powerful type systems of languages like C++ or Rust?

>>27313 >APL will be fine. name 3 relevant software written in APL meanwhile unreal engine is getting vectorization by using ISPC just fine. https://www.youtube.com/watch?v=OZwfVgnslDE

Any langs more suckless than C? I think the gcc's pretty bloated and that we could probably try and get our coreutils down to down 50 LOC at worst? Assembly doesn't count since it's like ripping nails out. Anything higher level than Assembly but lower than C? I want to get some really tiny, really fast binaries with as few bugs as possible (I am a very good coder)

>>27878 Name 3 in COBOL without looking them up. This proves nothing except your personal interest in the language and memory of trivia.

>>27895 >Name 3 in COBOL without looking them up. can't >This proves nothing except your personal interest in the language and memory of trivia. it proves that COBOL is a dead language. >inb4 muh banks yes, legacy soykaf, no one writes COBOL anymore. which just proves my point of it being a dead language.

>>27894 >coreutils bloat Go see suckless sbase, can it really be less bloated than that? >more suckless than C The most "suckless" language for a *nix system is C. This is because all the bloat is hidden in the libc and (POSIX-compliant) kernel. The truly "suckless" language that isn't assembly is Forth. Forth is capable of bootstrapping itself as an interactive interpreter with relatively minimal assembly on bare metal. I still don't understand all these "suckless" people. It's essentialy what >>27313 said, they hate bloat and complexity just long enough to stop at C and POSIX. Why stop at that exact point?

>>27899 ever heard about _portability_?

>>27894 >Any langs more suckless than C? assembly

>>27894 Forth is way more "suckless" than C. Anyone who says C is simple and/or low level don't know what they're talking about.

>>27904 Yea, C is so high level I write all my device drivers in .Net

>>27905 https://queue.acm.org/detail.cfm?id=3212479

>>27905 >I write all my device drivers in .Net See https://www.microsoft.com/en-us/research/project/singularity/

>>27907 How would a device driver work without direct pointer access? An Intel 8254x card, for example, would identify itself and provide a base address. A device driver needs to modify memory relative to that address. Can the device driver be written in Sing# or does it require unmanaged code? Is there enough information in a PCI header that the kernel can provide a bounded array object to pass to a managed driver? I don't understand.

>>27908 >How would a device driver work without direct pointer access? I'm re-entering this discussion to explain this. A device driver is merely a program which communicates with a piece of hardware. All that's necessary is to model the relationship. Now, this may require special access and data modelling abilities restricted from the rest of the system, and it may not. A language such as Ada can model data structures down to the bit-level, and specify addresses certain variables reside at; Ada can thus easily model a device driver in a safe way. A language such as Lisp would need some special abilities added just for this, to model things nicely and in specific locations. I don't know how the Lisp Machines did it, but I believe they either had every hardware device natively speak in Lisp data types, being able to be told where to find them, or each hardware device was made intelligent enough to speak Lisp more conveniently. Compare this to the C boil-the-ocean approach where everything is an imperative program that has to shift and sputter to massage data for the device.

>>27909 >A language such as Ada can model data structures down to the bit-level, and specify addresses certain variables reside at; Ada can thus easily model a device driver in a safe way. Who defines the mapping to raw memory? Does the PCI header provide enough information that the kernel can provide a data structure to the device driver or does the device driver have to define the mapping? It doesn't seem to. Using Ada to define a data structure that maps to specific memory locations sounds useful, but if the device driver is responsible for defining that mapping, then the device driver isn't managed.

>>27906 read >>27629 it's insane how nobody bothered actually reading that article and think somehow it's an argument against C. Everytime you hear "muh C not low level" or "PDP-11" you can be sure it's some drooling retard parroting this article which they don't even understand.

I think the "it lets you know how the computer actually works!" argument for C is a load of bull. The internal operations of a computer are as relevant to a programmer as the internal operations of a synthesizer are to a musician. Computers are mathematical instruments; they exist to solve problems, not make them. Resource management and type safety are the compiler's problem, not mine.

>>27911 C is so out of touch with hardware that it had to copy C++'s memory model to properly support symmetric multiprocessing. C++ is lower level than C.