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

Let’s sunset C/C++

trevorjim.com

Post reply on HN
Print view View original

131–137 of 137 posts

Re: Let’s sunset C/C++

#131

Post by pjmlp »

kevingoslar wrote: post #95
flohofwoe wrote: post #69

Earlier quoted context omitted.

To be clear, I love Rust's approach to safety. I just don't think it is an realistic expectation that we can re-implement all security-critical C code in Rust until the sun goes super-nova ;)

It's probably not going to be a rewrite of existing systems, but a switch to new systems written in safer languages while phasing out the old C based systems. On the server: unikernels. On the client: new mobile platforms, like OSes based mostly on web technologies (which while not quite being there yet are getting more and more powerful). C/C++ is not only a poor choice in regards to security, but also to develop fo…

On the mobile it is already kind of happening:

iOS slowly going Swift (Very few WWDC 2015 presentations were Objective-C)

WP 7 used only .NET. WP 8/10 use .NET and C++/CX.

Android uses essentially Java and Google only allows a very constrained use of C and C++ in their NDK.

So even though C and C++ are on the kernel and lower platform layers, at least the user space use is lower than on desktop platforms.

Re: Let’s sunset C/C++

#132

Post by pjmlp »

charlesL wrote: post #90

Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used. The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their h…

> So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great.

C compilers are fast today.

They used to be crap in the early 90's and seen as we see Python and Ruby performance nowadays.

Execution speed isn't a magic feature of C, not available to any other compiled language.

C is the systems programming language that allows for buffer overruns, memory corruption and dangling pointers everywhere in the codebase.

Other systems programming languages allow developers to explicitly only use those features explicitly when required. In C using strings is enough.

Re: Let’s sunset C/C++

#133

Post by pjmlp »

rrss1122 wrote: post #96

"I don’t see many people in the security industry taking up this call..." http://www.viva64.com/en/b/0324/ [Criticizing the Rust Language, and Why C/C++ Will Never Die ] "It is crystal clear for every sane programmer that C/C++ is not going to die in the nearest future. No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual ma…

To the point that Intel has poured millions of dollars into researching how to make C code safe.

https://software.intel.com/en-us/articles/introduction-to-in...

This is the real cost of language features.

Re: Let’s sunset C/C++

#134

Post by pjmlp »

carlosrg wrote: post #42

C++11 is pretty "memory safe". But obviously it allows the programmer go low-level and deal with dangling pointers if he/she wants. After all, the programmer/engineer is supposed to be a professional that can handle these things and make autonomous decisions.

Exactly!

When I use C++ alone, I use it like e.g. Ada or C#.

When I use C++ in a team, I cry how they make it C with a C++ compiler.

Re: Let’s sunset C/C++

#135

Post by vu3rdd »

I think a lot of comments in this thread are too harsh. I am a C programmer myself and see the value of it in embedded systems, operating system kernels etc.

While it is possible to write correct programs in C and C++ (which are very different languages, but usually mentioned together because of their names and history), it is too easy to make mistakes that are not caught by the compiler. It is easier to be sloppy in C than in say, Go or Rust. I have seen this in my own code and also in others' code.

C is not the only way to write system programs. Oberon, Inferno are good examples of OS environments written in safer languages.

But I agree that some of the disadvantages of C are also its advantages.

The author of the blog post has more followup posts:

  http://trevorjim.com/why-safe-languages-are-the-best-way-to-achieve-memory-safety/
  http://trevorjim.com/an-unsafe-legacy/
  http://trevorjim.com/unsafe-at-any-speed/
[edit: fix typos, rephrase a few sentences, fix links]

Re: Let’s sunset C/C++

#136

Post by iofj »

DCKing wrote: post #56
flohofwoe wrote: post #30

Excuse my french, but: What a load of bullshit. It's not the language, it's the tools. Add a static analyzer pass to each C/C++ compiler which is switched on by default. Add clang-address-sanitizer-style code when compiling in debug mode, and also offer runtime checks as option for release-compiled code. Both combined would have caught 99% of memory safety issues that pop up now and then. If necessary extend the lang…

I don't understand this type of reaction every time the problems of C/C++ are highlighted. Yes, of course the problems can be migitated using tools, but clearly this is not being done or is not as thorough or practical a solution as making it the language's responsibility. There's hoops that you must jump through to make C/C++ safe and clearly this just doesn't happen in practice. The same hoops just don't exist for…

Well the time will come when you will realize that

1) every language has hoops to jump through to make them safe (e.g. garbage collection does not protect you from memory leaks) [1]

2) every 4-5 years or so someone comes out with a programming language/system* [2] (rust, go at the moment) that fixes it all and "encourages good practices" - and then the good practices change (e.g. microservices are making their second round. They're good for sysadmins/sres and very bad for programmers (because you have to serialize/deserialize everything and changes to the system propagate into potentially dozens of separate programs - and God help you if they're maintained by different departments)). I wonder what's next ? Data-oriented programming is the perfect solution for the problems of microservices, so that could be next I guess.

* they may call it programming language, they may call it a system. Of course, it's always both.

[1] https://www.youtube.com/watch?v=ydWFpcoYraU [2] Forth, C, COBOL (/mainframes), Pascal, C++, Oberon vs Modula-2, dBase (and it's competitors), Object Pascal/VB (the built-in database approach), Perl, Java, .Net, and now here Go/Rust

Re: Let’s sunset C/C++

#137

Post by chadzawistowski »

steveklabnik wrote: post #125
pmelendez wrote: post #124

Earlier quoted context omitted.

> In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If I am following you well, then what you are saying is that you if you are in a single thread application you don't need to use a shared_ptr equivalent. Wouldn't that mean that you are using a garbage collected pointer? (Which should have a greater overhead than a shared pointer) because otherwise you w…

> you don't need to use a shared_ptr equivalent Well, it's the same thing, but without the atmoics. Rc and Arc only differ in the instructions used to update the count, Rc uses regular increment, Arc uses atomic increment. The code is otherwise the same.

How confusing! Rust's Arc is "atomic reference counting" whereas Obj-C/Swift's Arc is "automatic reference counting"
Post reply on HN