In the past few months I've noticed a lot of comments along the lines of "C is a meme language" on here...

Yes.

Being an elitist faggot that pretends he has a job in the industry, when in reality he's just a faggot student with an internship.

...

I already know C and Go, I was more looking for criticisms from a language design standpoint

What is this place? Is this /g/? Why are there so many kids bragging about their poor knowledge?

Nice job mindlessly regurgitating shit you hear around.

What is there to learn about the C syntax? The language doesn't have that many features in it. It is very feasible to read the K&R book then update the knowledge with the current ANSI C standard.

It's worth mentioning that C is a systems programming language. Drivers and OSes will probably be coded in C for a very long time.

I don't think a OS coded in any other language will perform as well while still being extensible and packed with the right features.

imo though, I'm sure some autist will argue why the next MemeOS should be coded in Go.

That's the beauty of C. You want to do a for_each or "for ... in ..." loop? Fuck you, you're gonna have to learn how to index across arrays.

While you're at it, you'll also come across instances where you can optimize your code to run even faster than a for-each style loop.

C is the bare minimum, you have to implement algorithms by hand, and there's a lot of libraries. There's a lot of reinventing the wheel, but that's what makes it great. Sometimes different wheels are better for different applications.

C isn't a meme language, it's a special snowflake. C did things because they're different, like octal numbers begin with 0, arrays start at 0, strings end with 0, arrays can't be 0 length. Most of its special snowflake crap is like some guy just discovered the number 0 and decided to special case everything around it.

The only thing in C++ that's particularly ugly is template metaprogramming. Everything else looks as good (or bad) as C (or sometimes better).

ebin meme

It's all shills and shitty "programmers" that don't have any clue about how to write simple yet powerful optimized code and therefore don't understand why C is the king of languages. They probably think the only difference between languages is the syntax and once you compile (or interpret) it it's all the same thing going on down the hood.

Amazing, C sure is the bestest language evar

UNIX, boy. Everything is a file.

But not everything is UNIX.

Not everything matters.

Plenty of non-UNIX things matter. It's possible that they don't in your particular field, and then it's fine, but if you think everything is and should be UNIX you're part of the cancer holding computing back.

MSVC is the IE6 of compilers. You can only have pretty, efficient, reasonably-safe C code at the cost of excluding the large (albeit dwindling) win32 audience.

And you whine about C being "raw"? Nigger have you ever tried to use the heap of shit that is C++ stdlib threading?

UNIX a shit.

Who the fuck wants C++? That language has literally spent decades unsuccessfully trying to get away from the shitty C foundation it was built on.

Look at the code length ratios for C and C++:

blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/

Think of C like a hammer and chisel and high level languages like a jackhammer. C offers more precision and control while high level languages just get the job done faster with less control and precision. You don't choose one over the other for everything. You pick the best tool for the job.

C and Go have nothing to do with each other other than being poorly designed and worshiped by neckbeards. Aside from that C is sort of an academic idea in that you have to be careful to avoid invoking UB or else your program will not be guaranteed to do what your code appears to say. This has nothing to do with memory safety btw other than that the difficulty of avoiding stack smashing is compounded by this issue.

C has facilities for reusing other people's code on par with the rest of the popular bullshit (yes, the way to use someone's code is sling around a bunch of shitty macros, but that's not much worse than what PHP, Python, C#, Visual Basic, or Java do)

none of those "muh standard" issues you list actually matter, and in fact the most reliable way to do networking is directly with POSIX as opposed to some bullshit wrapper around it you get with the likes of Python, PHP, or Haskell. having raw pointers or not is a tradeoff. all mainstream PLs have garbage type systems, what's your point?

I love C++! I can recreate all kinds of Haskell features within STL! All the semantics of Haskell style FP with all control of template C++!

C's "worse is better" design philosophy is the exact opposite of what academics tend to want in their programming languages. As a rule, academics hate low-level or messy real-world computer/electronics concerns and seek to eliminate as much as possible the need to consider them while writing a program. This means no manual memory management, no primitive data types, no direct control over stack/heap, and support for abstracting away from imperfect reality.

This tends to result in languages that are very good for writing elegant programs for raw computation and proofing, but less useful for more low-brow (but not necessarily less technically challenging or impressive) projects like games and other user-facing applications.

Why do you people rabidly defend C when you never wrote anything worthwhile in C in your entire life?

I have no idea what you're talking about. My academic computer science colleagues have no problem implementing proof of concepts onto physical hardware after they prototype using virtual hardware. What they don't like is doing rote mechanical work that is easily achieved by a computer program.

Academics can design languages for systems programming. BLISS and PL/360 are academic languages.
The big complaint about C is the hacky design, not being low-level. Being low-level is the entire purpose of C. Every type besides int was bolted on, though the control structures were there since the beginning. Pointers, char, long, function pointers, arrays, structs, unions, const, enum, void, and typedef weren't there originally. A lot of the library was hacked together over several years too. All of this makes the language less coherent and more complicated than having everything all there in the original design.
Unfortunately, if you've never used a systems language besides C and C++, you won't be able to understand this because your concepts of systems programming are shaped by the C language.

C wasn't even used that much before ANSI C, at least on home computer platforms (not mainframes). The compilers sucked, and you were better off to write in assembly language, or even one of the nice BASIC dialects like GFA on Atari ST and Amiga. But earlier, instead of C they used Modula 2 or BCPL, also Fortran and Cobol. Actually BASIC and asm were pretty common on mainframes too. It took some time for C to really gain momentum outside of Unix (which a lot of mainframes didn't run).

Damn right they didn't. MULTICS was always better than that hackish knock off.

People always say that multics and ITS were great, but what was great about them? please provide one aspect of each that is better than unix.

...

Multics had unified memory/files, more advanced dynamic linking than even today, and vastly better security/error recovery in many ways than Unix.

ITS was a crowdsourcing no-security gimmick, so I don't know who's praising it.

I could say something about worse is better but this is fair

What do you mean by unified memory/files? Usually it's stallman talking about ITS or maybe I just made it up.

Are you retarded?

en.wikipedia.org/wiki/Single-level_store

...

C, C++, and Go are all deprecated now that we have Rust.
Anybody coding performant code, or code that has to interface with hardware, who is not using Rust is just wasting their time as their code will not be used or contributed to in the future.

Anything on chans sufficiently popular is subject to being classified as a meme.

People who want their code to run on CPUs other than ME/PSP/TrustZone-pozzed ones?

A garbarge language shilled by non-coders because they share views with a community of like-minded faggots.

btw garbarge is now a word, my quads deem it so.

Rust shills. Every single "argument" I ever saw against C has been a dumb weeb not acknowledging his incompetence. When someone tells you it took them an hour to sort an array (even in assembly), you know what you're dealing with.
I haven't used Go a lot, but from the little I did with it, it's a beautiful language. Same spirit as C but more modern (never did paralleling though). Its only flaw is stupidly big executables but it might be possible to fix this with a lighter compiler or something.

okay buddy, i think i know what i am dealing with here

...

Your average C fanboy.

Are you saying I'm defending C? C is garbage and so are the other PLs I mentioned.

This is true in theory and maybe in the original principles of the language, but in practice modern C compilers follow the unique academic idea of the compiler throwing out all guarantees once your program invokes undefined behaviour. If you use almost any other modern PL, there is no concept like this, and the same applies if you write programs in assembly.

In theory maybe. There's a reason why UB is a thing in C. You have simpler language with not as many features, but the guarantees that are there are meant to be rock solid - hence UB for cases where they're not sure that they'll be able to absolutely guarantee something across the relevant platforms.

Go was literally designed for Pajeet coding.

No you don't understand. In C when you overrun a buffer, all guarantees are off. The compile can do anything. In most assembly environments OTOH, it's know exactly what will happen in that case. In Java, you get IndexWhateverException. The problem with C is that UB is actually extremely hard to avoid and nobody does it in practice, and this leads to memory corruption bugs even if the UB invoked seemingly has nothing to do with memory corruption (such as shifting signed integers, or using a non-volatile variable which isn't sig_atomic_t or calling a non async-signal-safe function from a signal handler). Since almost no practitioners even understand that C is like this, C is by definition an academic idea.

Even in my own C code I don't bother to know which behavior is undefined because such rigor is costly and will put me at a disadvantage to the rest of the market. I only code C ironically.

And of course I can guess what most stuff in C will do since I have 10 years of x86 assembly experience, but even then I can still never be sure. The compiler might just decide to do some hardcore optimization I've never heard of (it's 10 million lines of code after all) and trip me up.