Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

Post reply on HN
Print view View original

921–929 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#921

Post by snovv_crash »

ssokolow wrote: post #916
snovv_crash wrote: post #326

Earlier quoted context omitted.

> we're seeing more and more clients take memory safety seriously Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.

I'm reminded of this quote, written in support of more and stronger use of systems for formal verification, like powerful type systems: > Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. -- Edsger W. Dijkstra, "The Humble Programmer" (1972)

Oh for sure, use better types to express the problem in ways that the compiler can catch mistakes. But... you do need to show at some point that your code actually does what you claim it does, even if just for a single use case; might as well piggyback sanitizers since you're running tests anyways.

Re: Dijkstra, I'm not trying to prove that the code has no memory errors, I'm trying to make sure none get triggered in production ie. the difference between computer science and software engineering. If there was a simple and easy way to do behaviour proofs I'd be happy to use that, but coq et al. are a real pain.

Re: It's time to halt starting any new projects in C/C++

#922

Post by snovv_crash »

sophacles wrote: post #907
snovv_crash wrote: post #895

Earlier quoted context omitted.

https://pcwalton.github.io/_posts/2013-06-02-removing-garbag... This came 2 years after C++11 was finalized, which introduced RAII memory management, threads, range loops and much more, and is the basis for modern C++. Of course, there are pros and cons to keeping backwards compatibility with old code. Personally I think it's an amazing technical achievement that the same code written in 1987 still works. Particularl…

There's a 3rd option between "break the world" and "keep everything the same forever". Look into rust's editions. Short version: any compilation unit[1] can declare which edition it is written for. The code in that unit must be valid under the rules of the edition, but different units with different editions can be compiled into a larger program. https://doc.rust-lang.org/edition-guide/editions/index.html [1] the com…

This is, of course, due to the fact that Rust doesn't have a language specification, just a compiler implementation. If an old version of the compiler has a bug, using an old edition will still have that bug. Contrast this with C++, using an old feature you can still benefit from the latest bugfixes, optimisations, target architectures and instruction sets.

With the new GCC Rust work I believe a new solution will need to be found, and it will end up more similar to the situation with C++.

Re: It's time to halt starting any new projects in C/C++

#923

Post by steveklabnik »

sylware wrote: post #920
steveklabnik wrote: post #758

Earlier quoted context omitted.

There is no syntax that allocates in Rust. This was one of Linus' big reasons for accepting it into Linux. Functions can call malloc or equivalent, and while constructors don't exist, destructors do, so you can call free in them.

the syntax implicit expensive free is the same issue than the syntax implicit expensive allocation. I clearly recall when I read early rust specs that I did not want that (and more). Additionally, I wonder if they fixed the other C issues, namely removing integer promotion, implicit casts (but different explicit casts for compile-time and runtime), enum, _generic, typeof, 1 loop keyword is enough, no switch, goto is…

> I clearly recall when I read early rust specs

Rust changed drastically before 1.0, so depending on when you read this, it may be 100% irrelevant.

> namely removing integer promotion,

Rust does not do integer promotion.

> implicit casts

Rust does not do implicit casts (often called "coercion")

> enum

Rust's enums can do what C's enums do, but are more powerful by default, you can add arbitrary data to them, not just a synonym for some integers.

> _generic

Rust has a full generic system. Very different than _generic.

> 1 loop keyword is enough

Rust has loop for infinite loops, while, and an iterator-based for loop. There's no do/while.

> no switch

Rust has 'match', which is like a switch but extra powerful, especially when combined with features like enums.

> goto is not harmful

Rust does not have goto. It would be harmful for the kinds of static analysis Rust does. Rust does have named break though, which can do many (but not all) of the things you'd do with goto.

Additionally due to RAII and the way errors work on Rust, you don't need goto for error handling like you would in C.

> have only sized primitive types,

Not 100% sure what you mean by this.

> change extern/static

I don't know what this means.

> Hopefully, rust does not have object-orientation.

It depends on what you mean by OOP, but in general, the answer is "no". There's no classes, no inheritance. You can do dynamic dispatch, but it's fairly rare.

> But I guess, I would drop that reading if I encounter a definitive nono again.

Given what you said about destructors, that hasn't changed, so sounds like you'd stop.

Re: It's time to halt starting any new projects in C/C++

#924

Post by JSoet »

gavinhoward wrote: post #435
Arnavion wrote: post #386

Earlier quoted context omitted.

>Find a memory bug, any memory bug, in my `bc` after 1.0. I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially no…

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

I am also wondering about your confidence given the fact that there are obviously memory bugs during development... what gives you so much confidence that no memory bugs exist in released versions? Do you have an extensive test suite with valgrind /etc to ensure that there aren't any memory bugs before a release but some can slip in in intermediate versions? Or what do you do that gives you the confidence to say that there aren't any memory bugs in the released versions? Or what is involved in all the extra effort it takes to make a memory bug free c program?

Re: It's time to halt starting any new projects in C/C++

#925

Post by NonNefarious »

sanxiyn wrote: post #153
NonNefarious wrote: post #41

Earlier quoted context omitted.

ABI shenanigans are what killed the whole "off-the-shelf components" promise of C++ and object orientation. They really made the same mistake again?

Rust wants to fix this, but it's an extremely hard problem and other tasks received higher priority. See "How Swift Achieved Dynamic Linking Where Rust Couldn't" for details: https://faultlore.com/blah/swift-abi/

Thanks for that referral.

On a side note: I like Swift for the most part, but the last time I looked at upcoming language features they seemed like a kitchen-sink approach that's bloating the language and would better have been left to libraries. I've read this sentiment in more than one place, too.

Re: It's time to halt starting any new projects in C/C++

#926

Post by [deleted] »

tejohnso wrote: post #584
41b696ef1113 wrote: post #125

Earlier quoted context omitted.

The true real win of Rust. Knowing that you are incredibly likely to be able to compile it without any hoops. Random C/C++ project can still be a roll of the dice.

> you are incredibly likely to be able to compile it without any hoops Nice. Does that hold true for cross compiling to arm (Rpi specifically) and Android?

[deleted]

Re: It's time to halt starting any new projects in C/C++

#927

Post by Tozen »

stouset wrote: post #811
gonzus wrote: post #651

Earlier quoted context omitted.

I was going to start this reply by saying "I am not necessarily defending / supporting ghoward's position", but after I read his whole reply, I realize I am. I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now", and "C is so dangerous in can…

> I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now"… Nobody is saying this! In the original tweet, Mark Russinovich said he thinks C and C++ should be deprecated. I believe if you asked him to elaborate on this, he would say he believes w…

Part of the issue though can be perceived psychological pressure, that can border on being coercive or even come off as intimidation. Kind of like all the "cool kids" are using X, and if you are not, then something must be wrong with you. And while Mark is probably not trying to purposefully create that kind of environment, remember there are powerful corporate interests involved, that probably wouldn't mind some intimidation or unnecessary peer pressure to promote their agenda.

Re: It's time to halt starting any new projects in C/C++

#928

Post by Tozen »

ncmncm wrote: post #783
Qwertious wrote: post #463

Earlier quoted context omitted.

I think they're thinking "how do we get those C++ businesses to switch to Rust" rather than "how do I bankrupt them".

They're thinking "how do we get those C++ businesses to stop hiring C++ coders, and start hiring us Rust coders instead". The original purpose of Rust was to displace C, a laudable goal. But it is failing at that, because C coders are practically defined as people who will never switch to anything. (Any who might have did already.) So now the only hope is to displace C++ instead, and the propaganda machine is trying…

Well, there is corporate financial interests involved, which is sure to push the propaganda machine into higher gear. Expect a lot more trash and FUD being thrown around by converted fanatics and speculators, in regards to all the "inferior" languages.

Re: It's time to halt starting any new projects in C/C++

#929

Post by kevlar700 »

Ada offers security and simplicity and is already part of GCC but also has llvm now. Linux kernel drivers have also been demonstrated.

Perhaps it would be healthier for Rust to have competition?

https://www.linux.com/audience/developers/hacking-the-linux-...

https://github.com/alkhimey/Ada_Kernel_Module_Framework

https://alire.ada.dev/

Nvidia also chose Spark; a built in subset of Ada as being more cost effective for secure code than C++.

https://youtu.be/2YoPoNx3L5E

Assembly is also supported by Ada and I found it far easier to add than with C even.

C interface support is also excellent.

Post reply on HN