Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

101–110 of 222 posts

Re: Goodbye C++, Hello C

#101
post #56

Earlier quoted context omitted.

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot…

> You can write safe C, if you are careful You can also live forever, if you have right combination of genetics and environment.

Like when someone says "Lisp is homoiconic," and that automagically creates a thread of people tripping over themselves to make the same points they do every time "Lisp" and "homoiconic" appear in the same sentence.

There should be a list of these language snowball avalanches somewhere. They work every time.

Re: Goodbye C++, Hello C

#102

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot…

> You can write safe C, if you are careful

In practice this pretty much cannot be done unless you use a formal verification framework, which almost no one does. Even the most well-resourced projects written in C tend to have trouble with low-level bugs. Same goes for C++. Both the Linux kernel and Chromium have plenty of these issues.

Re: Goodbye C++, Hello C

#103
post #15

If you really like the simplicity of C I highly recommend Nim: * Compiles to C, so you stand on the shoulders of giants wrt compilers. * Very low overhead GC that doesn't "stop the world". I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound. Nim got twice the throughput w/…

Use mmap and you won't need to write anything to disk; the operating system will do it for you. That's C's killer feature while also being the last thing on earth languages like Node and Java would ever permit developers to do.

Re: Goodbye C++, Hello C

#104
post #51

I just freakin' hate .h files... Writing pretty much the same thing but twice and in two different places for every function. Why?!? I would love C++ if not for them.

Then use modules, VC++ 20219 has the best support, GCC 11 has similar support, it is mostly clang that still had some catch-up to do.

Or use traditional C. The x86_64 System V ABI is well defined enough that I'm honestly not sure why we need prototypes. All we need is a compiler that authorizes us to use an ILP64 data model. Then we'll be able to write C the way it was intended to be written without the quadratic header complexity. C++ showed us where that path leads and I truly hope modules happen but it's about as likely as my hopes of restoring the good parts of K&R C.

Re: Goodbye C++, Hello C

#105

Earlier quoted context omitted.

Lunacy. What is the evidence for this? Look at all the locked-down walled-garden platforms proliferating, and this famously prescient story: https://www.gnu.org/philosophy/right-to-read.en.html 20 years ago, many people thought RMS was a completely insane lunatic. Yet now he seems more like a prophet. It's not hard to see where things are going if you read between the lines. Increasingly, "safety and security" is bei…

> Look at all the locked-down walled-garden platforms proliferating I don’t think I’m getting the connection here —- Rust was incubated at Mozilla and is now managed by its own open-source foundation. There’s nothing particularly closed or “walled garden” about it. By contrast, Apple’s ecosystem is the canonical example of a walled garden. But it’s overwhelmingly programmed in unsafe languages (C, C++, and Objective-…

With the possible exception of Rust, safety always had performance implications. Forcing people to write their program in C# or Swift or Java causes many programs to be slower than they really need to be, forcing us to either wait on them, or buy a faster palmtop.

(Now most devs don't care about performance, so they don't see that as a problem. As a user however I can tell you, I hate when my phone lags for seemingly no good reason.)

Re: Goodbye C++, Hello C

#106
post #100

If 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.

Re: Goodbye C++, Hello C

#107
post #106
post #100

If 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.

I measured that on an Intel(R) Core(TM) i9-9900. I understand that not everyone has the privilege of being able to afford a $1,000 computer. However those people usually aren't coders. It'd be great if I had one of those 64 core "specialist" workstations that people like googlers use to be able to compile projects like TensorFlow in a reasonable amount of time. My project would probably build in seconds. But alas I don't, so I need to forgo eigen and template metaprogramming.

Re: Goodbye C++, Hello C

#108

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

Can someone tell me what it means that "float is unsafe"? I'd never heard about that.

Re: Goodbye C++, Hello C

#109

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

Markdown ate some of your asterisks

Re: Goodbye C++, Hello C

#110
post #108

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

Can someone tell me what it means that "float is unsafe"? I'd never heard about that.

The * has been erased by HN's markup.
Post reply on HN