C

there isn't any, that's the tragedy of modern computing

>OP either is the NSA or a moron

I don't think NSA posting in Jow Forums or stuff like that

Also, GO could replace C in future, but idk I don't sure

This.
Any answer other than that is just autistic screetch from a fucking tech monkey.

see
and queue.acm.org/detail.cfm?id=3212479
The fact that it's still terrible to use stems from the fact that it's a broken, half-assed piece of crap.

If its the best ever, why didn't it get an A?

It got a B in it's youth

*generics blocks your path*

>hurr durr what is void*

it has its uses. take for instance a small program self contained for Embedded systems with small amount of libraries to do very small stuff. C++ would be too big, any other language would take too much space. So c is very simple and small and gives you a lot of control. I just used it in this semester in the uni. its very hard to use but i see some use cases where it would be a good alternative.

>hurr durr what is type safety

>Swift slaps your ass and steals your girl

>he can't be type safe without the compiler babbying him

While C has it's syntactical blunders, the real issue is general computer architecture. Most of the world is built on C in terms of abstraction. Look at any popular or esoteric language and you're almost guaranteed to find C somewhere in the chain.

It's extremely rare to not find this, and as far as I can tell SBCL (common lisp) is one of the few I'm aware of that actually goes directly from lisp -> assembly with their own assembler.

Rust probably won't be replacing C, since it ignores the fact that you have to get your hands dirty sometimes. Look at all the complaints of actually trying to write low level stuff in Rust, it's basically just using the 'unsafe' libraries to write C with Rust syntax.

GC'd languages are immediately out, so goodbye Nim, Go, and Red.

Although I think it's unlikely to happen, a shift back to stack machines would probably be more appropriate. Forth seems like a good contender with it's infinite levels of abstraction while essentially remaining close to assembly.

But I say all that to say that I think a language with strong introspection and a REPL should replace C, free from garbage collection and with a strong focus on making the lower level easy without allowing for the security/bug issues that come with C.

Attached: 3x7zxr5to8o01.jpg (846x960, 113K)

>intel trying to put the blame on C for making catastrophic mistakes
LMAO

_Generic and a macro baka senpai

Ada

Why is this even up for debate anymore?.
"C" is the easiest to learn, easiest to program in, produces the most efficient executables.
Anyone that uses other shit is a combination of pajeet, SJW or a brainlet,

>bloated slow to compile shit that is always statically linked
yeah no.

Only correct answer. It's amazing how much people forget about the only good modern systems language in existence.

_Generic replaces function overloading not templates/parametric polymorphism you fucking cretin.

>"C" is the easiest to learn, easiest to program in, produces the most efficient executables.
>Anyone that uses other shit is a combination of pajeet, SJW or a brainlet,
or actually understands computers and knows none of it is true

It is also one of the easiest to write incorrect, UB-ridden code in (second only to sepples, I think).

UB is completely evil when it's caused by how CPU instructions behave. E.g. adding 2 signed integers - ff language actually wants to solve this it either needs to make its own arbitrary sized integer type everywhere (see Lisps and Python) which makes everything by magnitude slower; or wrap it in checks which is also slow

>s/is/isn't/

IMHO, the problem that the author of the article is writing about is bigger than C and it started when hardware vendors started introducing many new optimizations (cache, later multiple layers of it, instruction-level parallelism, etc.) without exposing them in machine code for their devices. The first part of the article, "Fast PDP-11 Emulators", in particular holds just as true for x86_64 machine code (and assembly, by extension) as for C.

I agree that not all UB is evil.Without it, many optimizations would be impossible.
However, the idea that C (or sepples) is an easy language to program in, is questionable when you've got patterns like this:
blog.regehr.org/archives/385

that's not turbo pascal

>what is rust

>sjw
>nu males
>code of conduct
and this is supposed to be better than C.
neck yourself already

>Using a language responsible for missile guidance systems, battle tank embedded solutions, and fighter jets

Sorry, CIA nigger-san, but we cannot do this.

Attached: 1521307024106.gif (514x205, 1.96M)

youtube.com/watch?v=kqcc1nMKZ70

I don't see why adding signed integers is UB when casting two signeds to unsigned, adding them, then casting back is (rightly) implementation defined.

C is my mother tongue.