I can understand the point about compile times. For the rest, C++ is just superior and you cand do what you would do in C, just safer and add constexpr, consteval and careful templates for more type safety plus more type safety by default.
Goodbye C++, Hello C
201–210 of 222 posts
Re: Goodbye C++, Hello C
#202If you want a good case study in repositories that build quickly then check out cosmopolitan libc. Typing `make -j16` it compiles 15,383 .o objects, 69 .a static libraries, and 548 executables, 297 of which are test executables, which are also run by the make command, and all that takes just 40 sec.
Minor nit-pick: wouldn't that rather be make -j`nproc` ? Not everyone has an 8-core CPU with SMT or a 16+-core CPU respectively.
Not everyone runs UNIX and sh either.
Re: Goodbye C++, Hello C
#203Earlier quoted context omitted.
Those would be Pascal Strings (length at the start, then the bytes). Those make for very easy to write code, but they come with a few issues, but in general they are simpler and give better behavior than null-terminated strings. However, as for a bit of a historical bagagge, it seems we got used to null-terminated strings and just went on with them.
Only in C, even C++ has since the early days adopted proper strings on its standard library, initially the compiler specific ones from the early 90's, then the standard one.
Sure, its just that these kind of strings were historically called Pascal-strings [0] because they were the way Pascal implemented strings.
[0] And still are! For example, Python refers to them as such, see the "p" (lowercase p) character code here: https://docs.python.org/3/library/struct.html#format-strings
Re: Goodbye C++, Hello C
#204Earlier quoted context omitted.
> these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple. >> but perhaps in another decade or so, you might not be allowed to program in 'unsafe' languages on all other mainstream platforms, unless you register…
> Look at a platform like Apple. Every release makes it harder to run arbitrary code. The original claim was that "you might not be allowed to program in 'unsafe' languages on all other mainstream platforms". But Apple restrictions don't distinguish between safe and unsafe languages, they just restrict all arbitrary code, so this is not an example of the point being made, but rather an orthogonal issue.
I was responding to the broader point that security is used as justification for making systems less accessible to programmers.
Apple doesn't distinguish between safe and unsafe languages for now, but it's not impossible to imagine this becoming a restriction in the future, given the broader trend.
Re: Goodbye C++, Hello C
#205Earlier quoted context omitted.
> Rust is not a C analog. The whole value proposition of C is simplicity, and Rust is anything but simple. I would say the value proposition is control and performance, and more pragmatically ubiquity. If the value proposition were simplicity, why aren't C programmers writing Lisp instead? If it's simplicity and control, why aren't they writing assembly? At this point, C is little more than a bad abstraction that peo…
> I would say the value proposition is control and performance, and more pragmatically ubiquity. If the value proposition were simplicity, why aren't C programmers writing Lisp instead? If it's simplicity and control, why aren't they writing assembly? At this point, C is little more than a bad abstraction that people are nostalgic for. Because it is hard model hardware in idiomatic Lisp and Assembly in not portable a…
I agree - C is a sweet-spot language. It shows its age in certain ways, but it remains a relevant language 50 years after its inception because it strikes a very pragmatic balance between being simple and easy to understand, and in being a fairly thin abstraction over the hardware.
Re: Goodbye C++, Hello C
#206Earlier quoted context omitted.
Only in C, even C++ has since the early days adopted proper strings on its standard library, initially the compiler specific ones from the early 90's, then the standard one.
Sure, its just that these kind of strings were historically called Pascal-strings [0] because they were the way Pascal implemented strings. [0] And still are! For example, Python refers to them as such, see the "p" (lowercase p) character code here: https://docs.python.org/3/library/struct.html#format-strings
Not all C++ string libraries use Pascal strings.
Some of them use a fat pointer instead, with a mix of counter, pointer to the end, and null terminator for C compatibility.
Re: Goodbye C++, Hello C
#207Earlier quoted context omitted.
I didn't say anything about C++. Rust is a very complex language. You can argue about whether it's more or less complex than C++, but it's certainly on that end of the spectrum. C is way on the other end. That's not a value judgement of Rust, just an observation.
> C is way on the other end. Rust is complex, but I think it’s honest in its complexity: it straddles programmers with lifetime management in exchange for better optimizations (alias analysis is a pain in C!) and memory safety. This is in contrast to C: it’s very easy to write C that compiles, but very difficult to fully evaluate its correctness. Part of that is the extraordinary complexity of the C abstract machine,…
There is something true in what you are saying, but I still think the difference in complexity between Rust and C has much more to do with the very different goals of the languages rather than C just hiding complexity from the programmer.
Rust targets a much higher level of abstraction than C. The machine itself is at arms-length, and you are mostly thinking in terms of an abstract type system and borrow checker rather than a CPU and memory system. A lot of rust programming is declarative, and a lot of the complexity comes from finding the right way to express your intent to the compiler through the various systems of the language. The tradeoff for that complexity is that you get to write programs with very strong safety guarantees, correctness benefits, and low performance overhead.
C is about having simple, imperative control over the computer hardware. With C you are thinking in terms of the CPU and the memory system, you are mostly just telling the computer exactly what you want it to do.
C definitely does have some failings: for instance as you allude to, C doesn't ensure that all failure modes are encoded in the function signature, so it's not really possible to audit a C program for correctness by reading the source alone, the way you can almost do with Rust.
But that doesn't mean that the level of complexity which comes with Rust is necessary to fix the issues with C. Zig is a good example of trying to plug some of C's holes without increasing the level of abstraction.
Re: Goodbye C++, Hello C
#208Earlier quoted context omitted.
But I don't understand how data stealing can happen if each process is effectively sandboxed. If my process can't read or write to memory outside of what it allocated, how can I corrupt or steal user data?
In case of a browser, a buffer overflow can be exploited to upload user files for example — which are very much readable without trouble on most linux distros.
But again, isn't that the OS failing to protect user files rather than an issue of memory unsafety?
Re: Goodbye C++, Hello C
#209Earlier quoted context omitted.
In case of a browser, a buffer overflow can be exploited to upload user files for example — which are very much readable without trouble on most linux distros.
But again, isn't that the OS failing to protect user files rather than an issue of memory unsafety?
That's another aspect of it. Please see this answer of mine:
https://news.ycombinator.com/item?id=27642630
In short, memory unsafety makes programmer bugs exploitable, instead of generally just failing.
Re: Goodbye C++, Hello C
#210Earlier quoted context omitted.
But again, isn't that the OS failing to protect user files rather than an issue of memory unsafety?
That's another aspect of it. Please see this answer of mine: https://news.ycombinator.com/item?id=27642630 In short, memory unsafety makes programmer bugs exploitable, instead of generally just failing.
I understand what you are saying, and I understand that this is a real security issue in modern computing. However I would put the question to you in a different way:
Let's say we have two programs, A and B.
Program A by its very nature needs to have write access to the system's file permissions in order to fulfill its core purpose.
Program B only needs R/W access to a sqlite database installed in a specific directory, and the ability to make network calls.
I would agree that for program A, a memory-safe language can provide a very real benefit, given the potential risk compromising this program could expose the system to.
Would you agree that if a buffer overflow exploit in Program B can be used to compromise the system outside of the required resources for that program, this is a failing of the OS and not the programming language?