Thank you, that means so much coming from the best! I will definitely follow that advice if I end up making another video. I was having a lot of trouble with my adsense account which was killing my motivation, but hopefully the situation can be resolved in the future. Until then I will learn as much as possible to have some material for the future! ;)

There is nothing unsafe about C. People simply don't know how to use it. I also doubt that Rust can beat properly optimized C code if the compiler optimizations are the same. It might not even be the code. Individual results might have something to do with cache hit/miss rates or pipelines rather than the actual code. Even LLVM can not optimize that since it's strongly data dependent.

​@@lepidoptera9337C is unsafe because its memory model is unsafe. Unless you use C11 atomics (which didn't even exist prior to 2011), C provides no guarantees about memory access at all. The problem is that every platform/CPU has its own memory rules and you would have to make sure to write C code that follows those rules but since those rules vary by platform/CPU, it's actually not truly possible to write C code that is guaranteed to work correctly on more than one platform. If it does, that's plain luck. Modern programming languages like Rust, Swift, Go and even Java and C# do define a memory model as part of the language that is valid for all platforms the language supports. It's up to the compiler/interpreter to ensure that this memory model works as defined by the language on the platform, no matter what is required to make that happen. The programmer doesn't have to adopt his code to any platform for those, the programmer can rely on what is defined in the language standard. Here's a very simple example: You have a global variable of type int, whose value is currently 0 and you change its value to 10 in thread A. 30 minutes later, the variable has never been touched ever since, you read the value of the variable on thread B, what will the value be? 10? Show me where the C standard makes that guarantee. Fact is: It doesn't. Prior to C11 C didn't even acknowledge the existence of multiple threads. But even without threads: You only have one thread, that runs on CPU 1 and you write a value, 30 minutes later the SAME thread runs on CPU 2 and reads the value. Again, where does the C Standard guarantee that CPU 2 will see the value that CPU 1 has written? It doesn't, because C does not acknowledge the existence of systems with more than one CPU. And what applies to CPUs also applies to cores of a single CPU. Only when using atomic variables as defined by C11, there now is a memory model and you as programmer can even choose between 6 different memory models but for everything that is not atomic, nothing is defined. Without atomics, the way you think C works in fact only works if all your code is always running on a single thread only and your system only has one CPU core or if you are lucky and the CPU does make that guarantee in hardware; like x86 does most of the time but PPC, ARM, Alpha, RISC-V, etc. doesn't make those guarantees. That's why so much C code that worked flawless on x86 CPUs fore decades suddenly breaks when it has to run on other CPUs. The code was never correct in the first place but x86 is very forgiving and gives a lot of memory access and ordering guarantees that other CPUs don't. So you basically had C code, that was valid for x86 in particular but that doesn't make it universally valid, as there is no such thing as universally valid C code, because C leaves most definitions to the system, instead of defining it to the language. This is also true for plenty of other situations. E.g. what happens if a signed int overflows? Not defined in the C standard. What happens when you de-reference NULL? Not defined in the C standard. What happens when you shift a 32 bit integer right by 32? Not defined in the C standard. Of course, on every platform the behavior is defined but the definition varies by platform, that's why modern languages define it as part of the language. As for performance, I have a C code sample, that calculates a Mandelbrot set. It's as basic as this calculation can get (three for loops, an array of float values, some simple int and float calculations, one static function being called from within the main for loop). When I compile it with clang using -O3, the code runs slightly slower as when I take the code as is, convert it to Rust (which almost requires no adoption, except for the data types and the function definitions) and compile it with the Rust compiler. Reproducible on x86 and on ARM CPUs. If KZbin would allow external links, I'd show you the code and I take any bet, you cannot make the C code run faster than than the Rust code, as there is nothing you could optimize about that code and there is no better optimization than -O3.

​@@lepidoptera9337If I could post links here, I could show you a simple Mandelbrot calculation code that will run faster in Rust than in C and I bet that there is nothing you can do to make this code run faster in C, as this code is minimalistic and there is nothing you could optimize that the compiler cannot optimize 100 times better than you and still Rust always wins on x86 and ARM with both compilers set to maximum optimization. And C is unsafe because it does not define a memory model (only for atomics which only exists since 2011) and it also has tons of undefined behavior, where the C standard simply does not define what the outcome of an operation will be. This makes it very easy to port C to any platform but it also means that the same code will not behave the same on different platforms. Modern languages have a well defined memory model and well defined behavior and it is the task of the compiler to ensure this behavior on all supported platforms, no matter what is required to make that happen, so you can rely that the same code will produce the same results on any platform.

rust without llvm and gcc doesn't even exists and this people are morons XD all their code works with or thru c++ yet they don't like c++ and c cuz they are just bunch of looser typescript developers who never heard of memory managinG XD their brain cannot just process the new info about compuer science : D

It is trivial to avoid that. If it happens to you, it's basically just a feedback from the compiler that you don't understand what you are doing. Nothing to fear. You just have to start learning.

segmentation fault came from OS not from c lang kid . it has nothing to do with c . its comes when some morons code and they don't know what they are doing XD

javascript with crapy syntax at least in js you aren't forced to use crap things you can use just variables and functions and never use class or anything like that X

What?

@@dynfoxx This is only the case for what I said in cpp, but it still applies to data in general. Otherwise everything would be refed. But you never seen an int referenced in a function, or any basic number.

Porting from C++ to Python doesn't make any sense to begin with.

These attributes exist because the compiler can not know how you want to use a piece of memory... as a variable or as a constant. There are good reasons to store constants in a different area of the memory than the variables. C let's you chose that (and a lot more). Rust does not, as far as I understand. It makes educated guesses for you, which may or may not be correct.

fix your ears

also should someone beginning with Computer science field; learn C or Rust

Thanks god, someone pin this guy

Finally someone with a balanced opinion and not a C++ or Rust fanboy, blinded by their love for a language.

That's correct even if that's not what he's saying.