C is not a good language. Off-by-one errors are common in using the C library because it is not consistent. Sometimes you have to subtract 1 byte, functions like fgets() and strncpy will never write past the length given them (fgets() subtracts 1 itself, and only retrieves (length − 1) bytes), strncat will write past the length given them. So the programmer has to remember for which functions they need to subtract 1.
>This code that you've written is undefined, so you're not allowed to comment on compiler behavior!
The most recent time I saw this, another language lawyer then jumped in to argue that the code in question wasn't undefined as if this side discussion had any relevance to the real issue.
It's no secret that we have the technology to prevent most of these bugs. We have programming languages that practically guarantee important classes of bugs don't happen. The problem is that so much of our software doesn't use these languages. Until recently, there were good excuses for that; "safe" programming languages have generally been unsuitable for systems programming because they don't give you complete control over resources, and they require complex runtime support that doesn't fit in certain contexts (e.g. kernels).
Rust is changing all that.
>>55103724
Java has changed that decades ago.
>>55103724
Most of the expolits that affect the software industry have their root in a badly written C program (but I'm repeating myself).
C should've died a long time ago.
>>55105094
This, fampai.
>>55105094
>C should've died a long time ago
retards like you should have ended themselves long time ago
>>55103724
>i don't want to be responsible for the code i write
>>55105275
You don't even true arrays. Why do you even bother getting up in the morning?
>>55105400
I do even, why don't you?
>mfw developing kernel for raspberry pi 2 in rust
Not gonna lie rust is pretty lit senpai.
>>55105400
>checkedint c checked[10][10];
http://research.microsoft.com/en-us/projects/checkedc/
>>55107121
>let's take this 8 wheel truck and put 20 jet engines arround it, so it can fly
>problem?
>>55103724
Daily remind rust is not going to replace C/C++, ever.
No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual machines, databases, archivers, audio and video codecs, tons of other C-libraries, and so on and so forth, into other languages. This is a huge mass of fast, debugged, and time-proven code. Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. The demand for C/C++ programmers has always been high and will remain so for a long time to come.
How about Rust being used in the future instead of C/C++? Well for that to happen Rust would have to be as fast as C/C++ which it isn't:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
I sincerely hope that programmers will find a way to speed it up in time, but until then, it's going to be of hardly more interest than Scala or Go from the viewpoint of the safety/speed compromise.
>>55107373
Rust will be as fast as C++ when the compiler and test implementations get a bit better
>>55107503
The question is still open if it is possible at all to make a language both fast and safe or if it is automatically doomed to be twice slower than C/C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.
>Rust will be as fast as C++ when the compiler and test implementations get a bit better
I hope they do but I suspect you are being wishful.
Even apart from that speed/safety compromise issue, I'm also skeptical about the language's design as such. In particular as regards to the five types of pointers used in it. On the one hand, it's not bad to make programmers ponder if their variables are stored in the stack or heap and if they can or cannot be handled by several threads at a time. But on the other hand, imagine you are writing a program and discover at one moment that some variable should be stored in the heap instead of the stack. So you rewrite the code to use Box. Then you figure out that you actually need Rc or Arc. Again, you rewrite all that code. And then, once again, you rewrite it all to have an ordinary variable in the stack. All of that you have to do without a decent IDE at hand. Regular expressions won't help. Or you might justend up with a nightmarelike "Vec<Rc<RefCell<Box<Trait>>>>" - say hello to Java! But the saddest thing about it is that the compiler already knows everything about the lifetime of every variable and could automatically insert all those Box's, Arc's, etc. But for some reason, this duty was shifted on to the programmer. It would be much more convenient to let the programmer simply write val (we are living in the third millennium, after all!) and explicitly specify Box or Rc where necessary. From this viewpoint, Rust's developers have screwed up the whole thing.
>>55107373
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp
Rust is faster than C++ and as fast as C, the only problem is lacking support for SIMD
>>55107588
>constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that
Rust doesn't do "constant checks for array overruns"
Rust achieves memory safety by imposing a set of restrictions on how the programmer can write code, and through rigorous compile-time checks. It does not do the sort of checks you're thinking of during runtime.
>>55107588
Rust's safety doesn't have a run-time cost
>>55107697
>>55107726
Sorry, you are both right I didn't actually mean to fault Rust with that one. As I understand it, Rust built-in code analyzer and it's a pretty tough one: it can catch all the bugs typical of C++ anddealing not only with memory management but meltithreading too. Pass a reference to an assignable object through a pipe to another thread and then try to use this reference yourself — the program just will refuse to compile. And that's really cool.
But C++ too hasn't stood still during the last 30 years, and plenty of bothstaticand dynamic analyzers supporting it have been released during this time. Just as one example, watch a short video about Google sanitisers — they are reallyverytough. Anyway, in any serious project, you use a continuous integration systemand run tons of tests when compiling builds. If you don't, then your troubles are much worse than the language's lack of safety because static typing doesn't guarantee correct execution logic! So, since you run tests anyway, why not use sanitizers as well? True, they don't find all the bugs. On the other hand, if you don't have a check for an array overrun somewhere at the deeper levels of your code and a sanitizer doesn't report the bug, maybe it's just because all the necessary checks are already provided one level higher and another one would only slow down the program? Even without sanitizers, you'll find lots of stuff just building the project with various compilers on different platforms with assert's checking your code's invariants in the "assert(obj->isValid)" fashion and with proper fuzzing.
>>55107588
>But the saddest thing about it is that the compiler already knows everything about the lifetime of every variable and could automatically insert all those Box's, Arc's, etc. But for some reason, this duty was shifted on to the programmer. It would be much more convenient to let the programmer simply write val (we are living in the third millennium, after all!) and explicitly specify Box or Rc where necessary.
Those are implicit coercions, which are just operations you don't have to write down.
>From this viewpoint, Rust's developers have screwed up the whole thing.
The Rust developers fell for the "coercions are bad" meme.
>>55103724
C is fine. It captures the fundamentals of computing. Anything more complicated than it is over-complicating things and probably forcing you in to using potentially un-optimal patterns.
Improve your libraries and processes if you're constantly tripping over yourself. You'd be making the same mistakes in any low level language. C++ provides everything you need for using a powerful, zero-cost type system on top of C.
The standard libraries are shit, but that's common practice for every language in existence.
>>55103724
You would be better investing your time into studying C/C++ rather than Rust in the next 5 or so years. C++ is anindustrial standard.Programmers have been using it to solve a huge variety of tasks for over 30 years now. As for Rust and stuff like that — they are just odd toys with vague future. People have been predicting C++'s soon death since the 2000-s, but C/C++ hasn't become less used and demanded for since then. Quite on the contrary, in fact. It is evolving (C ++11, C++14), new tools are released (takeCLionand Clang, for example), and the number of vacancies is just huge.
A C++ programmer will hardly ever have any difficulties finding a job with a more than worthy saleryand, if necessary, can quicklylearnRust. But the opposite scenario is very, very unlikely. By the way, the language choice is far not the only and most important factor when picking a new job. Besides, a skilled C/C++ programmer can easily find their way in PostgreSQL's or Linux kernel's source code, has access to modern powerful development tools, and has a pile of books and articles at hand (for example on OpenGL).
>>55109140
>C is fine. It captures the fundamentals of computing.
This is what CS undergrads actually believe
>>55109487
This is what engineers believe.
Anything that doesn't describe the parts in your computer box is irrelevant and imaginary circle-jerk material.
>>55105275
bump
>>55109609
>Anything that doesn't describe the parts in your computer box is irrelevant and imaginary circle-jerk material.
The fact is that C isn't really close to the hardware anymore. C was fine on single processors without a memory hierarchy, nowadays we have caches and multiple cores, does the language reflect that?
>>55103724
>So the programmer has to remember for which functions they need to subtract 1.
Whoa, I need learn what a function does before calling it? What is this bullshit
>>55109726
Consistency goes a long way, kid.
>>55109694
It reflects the user code blobs that the CPU runs. There is no way for code to be inherently single or multi-processor, it's down to the commands it uses. Real "multi-processor" code works by creating multiple copies of the same program to run on each processor, but the code blob is just a single entity.
The languages which are "inherently" "multi-threaded" mean they just force you in to their shitty abstraction/library/system for interacting with the kernel's threading libraries.
>>55109815
>It reflects the user code blobs that the CPU runs.
No, assembly does that.
>>55109786
there is no need for consistency here. fgets reads an inputs and fills it to a buffer with n chars. it does not exceed n chars. It makes sense to subtract 1 because it is a buffer size
strnpy copies maximum n characters from one to other. It is not related to buffer size at all. why would it subtract 1 here?
>>55109860
Assembly is just a way of directly representing those blobs in text.
C is basically the only user-friendly language that can basically be 1:1 mapped to/from machine code conceptually, and in practice, give code that resembles the structure of the original (as if it were written in C).
You can break that mapping by writing self-modifying code, creating your own calling conventions, not using the standard stack, but the things C enforces on top of machine code are not many.
>>55109609
Your computer doesn't have "undefined behavior" in the sense of the C standard.
>>55109694
C was only close to one kind of machine: the PDP-11. Did you ever wonder why so little software used segments, separate stack segments, proper overflow checking, bounds checks, or many other features the CPU designers put there for you to use? Do you know why C doesn't use "ret n" to automatically pop arguments on x86? That's because C isn't close to the hardware.
>>55109815
>they just force you in to their shitty abstraction/library/system
>>55109950
>but the things C enforces on top of machine code are not many.
You can say the same thing about stacks, function pointers, varargs, and floating point. Not all hardware has support for those. C forces you into shitty abstractions. What if you want coroutines? What if your CPU supports segments, I/O ports, or display registers for nested procedures? What if you want to access the carry flag?
>C is basically the only user-friendly language that can basically be 1:1 mapped to/from machine code conceptually, and in practice, give code that resembles the structure of the original (as if it were written in C).
C forces you into a dumbed down least common denominator.
>>55110033
>C forces you into a dumbed down least common denominator
C language bikeshedders are literally the least common denominator of /g/ user.
>>55110033
All very good points, but unfortunately none of the "C killers" focus on those issues rather than "how can we make it more like javascript".
>>55110033
>Do you know why C doesn't use "ret n" to automatically pop arguments on x86? That's because C isn't close to the hardware.
Because of varargs.
Windows stdcall's (which is C code) uses ret n.
>>55110033
>stacks
>C forces
C doesn't say anything about stacks
>>55110549
I think the language that will replace C has to give you more control, not less.
>>55111070
Assembly?
>>55105026
You can't be this retarded... Java needs a JVM to run, a JVM ran in...
You guessed it, C. You programming language obsessed autists don't understand that it's not how good or bad a language is, but it's application. You can't write an OS in Java because java needs an OS to run.
I'm a fan of Rust because it's designed to be a systems language, a language that addresses the shortcomings of C that could make an OS in theory.
>>55111070
not gonna happen; the incompetents can't even handle the power of C
>>55111141
What if someone wrote a real compiler for java?
>>55103724
>strncpy
>strncat
your lack of experience is obvious
protip: you don't need them
>undefined
>relevance to the real issue
the real issue is you're incompetent and thus you're not entitled to an opinion
>>55111162
Java was designed to be compiled. Maybe in theory there could be a compiler, but it'd be incredibly impractical.
Languages like Rust are designed to be compiled, so they have a chance. Although desu C will still probably reign supreme
>>55111461
*designed to be interpreted
>>55110033
>C was only close to one kind of machine: the PDP-11.
but it was literally designed for portability
>>55111240
>protip: you don't need them
and if you do, there are safer alternatives
>>55107503
> as fast as C++
> slower than C
hahahahahahaha
>>55111461
>>55111665
Java isn't really an interpreted language though. It compiles to JVM bytecode, which is just machine code for a virtual machine. When you convert a .java source file to an executable .class file, it's still compile-and-go just like compiling a C program, only difference is the output is JVM bytecode rather than native machine code. But that doesn't mean it's "interpreted", unless you consider CPU emulators to be interpreters.
And as far as the language itself is concerned, it doesn't matter what kind of machine code it's compiled to. The main distinction between interpreted and compiled languages is that interpreters generally go one line at a time, so each line has to stand on its own, or at least only have its meaning be dependent on PREVIOUS lines. Whereas a compiler can look at the whole program before executing.
