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

661–670 of 929 posts

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

#661

Post by Cthulhu_ »

foomatic wrote: post #184
ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

I mean I could learn C++, but I don't wanna. I did some of it back in school (game development) and I don't particularly care for it. I don't want to do memory management myself or even have to worry about it.

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

#662

Post by svnpenn »

ninefathom wrote: post #242

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

> Rusties

please don't

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

#663

Post by alkonaut »

Ygg2 wrote: post #448
kramerger wrote: post #332

Earlier quoted context omitted.

Well... He is also written some horrible fiction novels, so the guys is not perfect.

Why are fiction novels relevant to field of computer languages? This seems like ad hominem.

This is a tounge in cheek jab at someone who is successful, rich, handsome, has a huge job title, is a famous programmer, and also sells a a lot books (because they are very popular). The fact that those books read like they were written by a 17 year old actually gives me some comfort...

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

#664

Post by School-Cotton »

sylware wrote: post #646
School-Cotton wrote: post #630

Earlier quoted context omitted.

When did I say rust is actually C++? I said its memory allocation model is the same: normally done in containers or smart pointers, but malloc and free are still available under the hood if you really need them. Many other things about rust are extremely different from C++.

Ok, now I see the semi-colon. So rust has heavy memory allocation implicit in the syntax (not meant only for the stack). I remember now I did not want that (like those horrible c++ new/delete). Thx to have refreshed my memory about rust syntax.

It's very unlikely you would ever have to use something like C++'s new/delete in Rust unless you are doing something like re-implementing the Vec class.

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

#665

Post by metaltyphoon »

dan_mctree wrote: post #526
lbriner wrote: post #492

Earlier quoted context omitted.

I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever! Most of us don't have the funding, skills, time, priority to rewrite all of our old web forms apps even if we wanted to. Who is going to pay to rewrite the app that only earns us $10K a year? Even if we did decide that Rust is great, do we immediately expect our C++ senior devs to produce the same quality code in a language they…

>I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever! The amount of global manhours MS is throwing down the drain by constantly ending support for their versions must be absolutely staggering. Updates are often far from trivial, and they expect everyone to keep up with their fast upgrades and tiny support windows? Long term support is only 3 years, are you kidding me?

> Updates are often far from trivial

No, they are actually trivial starting from 3.1/5/6 exactly because of the work they have put in.

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

#666

Post by kimixa »

Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operations (avoiding raw pointer arithmetic, no manual new/delete memory management etc). Comparing Rust against the overlapping subset of "C" and "C++" is rather disingenuous. It's like writing /everything/ in Rust in an unsafe block and avoiding all the tools that actually make it a more productive language.

I'd agree today you totally shouldn't be starting new projects in C-with-classes style C++, and take advantage of all the newer tools available in newer versions instead. Sure, Rust and similar may have even better tools to help the programmer, but talking about raw productivity, especially in shorter projects, learning a new language and all the fumbling and mistakes and anti-patterns that can hurt the result, as well as longer-term maintainability, may be worth consideration. Especially, as even if the core project is brand new code, the library ecosystem it's working in may still be more mature around other languages.

It totally makes sense to me relegating C and older-style C++ to systems where it's really the only choice (platforms with older/poor tooling, places where the resulting code requires more massaging than usual like resource-limited embedded situations and the developer is already skilled in this with their current toolchain, other situations that no doubt some people will find etc etc.)

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

#667

Post by svnpenn »

Xcelerate wrote: post #494

I’ll controversially go a step further and say we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers. From working with security at a large tech company, it’s abundantly clear that C/C++ should not ever be used for processing sensitive information (it’s fine to keep around for high performance computing or processing n…

> we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers

wow that is an awful idea

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

#668

Post by pornel »

scoutt wrote: post #629
pornel wrote: post #557

Earlier quoted context omitted.

There's very little overlap between HN commenters lamenting about colors of async functions, and actual Rust programmers writing async software. Rust's crates.io has over 15000 packages using async. Cloudflare has just replaced their nginx with a Rust proxy that uses Rust's async. Apple has hired Rust programmers for their storage and networking teams. Rust has been out for 7 years now, and detractors on HN still tre…

But don’t you think if Rust meant to be so popular and successful wouldn’t be it already, in this time and age? Like other languages since 2000? (Rails, typescript comes to my mind) Rust has given all its arguments. Has proven its goodness. What do you think it is stopping the world from adopting it? Another year is passing. The biggest news is that it might be included in the kernel. But it just requires a bad Linus…

I think Rust is already incredibly successful for what it is.

Rust isn't aiming to replace Ruby or TypeScript. Rust is focused on being a high-performance systems programming language. It makes big sacrifices to avoid having a garbage collector, VM, or other significant runtime dependency. For maybe 99% of programs having a GC or VM is perfectly fine, and you have lots of nice languages to choose from there. But Rust focuses specifically on areas where Ruby and TypeScript are poor choices or even entirely impossible to use.

Rust's popularity has already surpassed other C/C++ alternatives like Ada, D, Nim, Pascal, Cyclone, Checked-C, Zig, and depending how you measure, even Objective-C. It is already confirmed to be in the next Linux release. None of the previous C killers got even close.

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

#669

Post by Ygg2 »

jamincan wrote: post #635
ncmncm wrote: post #555

Earlier quoted context omitted.

No. I mean that there is a great deal C++ can capture and present in a library that cannot be expressed in Rust. Much of this will never be in Rust because of this or that early choice of direction. At the most basic level, in Rust you cannot overload operators. You have no opportunity at all to code a move constructor. I could list off others all day long, but you probably would not understand most. Then there are t…

> At the most basic level, in Rust you cannot overload operators. I've heard this claim multiple places and I don't really understand it. Operators have corresponding traits that you can pretty easily define for your types. https://doc.rust-lang.org/std/ops/index.html#traits

My reading is that Rust doesn't allow overloading of constructors (don't exist as such) or assignments or whatever is actually needed for copying move constructors.

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

#670

Post by chriswarbo »

zerr wrote: post #503
virgulino wrote: post #251

You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…

With all due respect, this is coming from a Win32 API C programmer who happens to save the code in files with .cpp extension. In other words, not familiar with modern C++.

Irrelevant. All the old, problematic approaches are still valid code, and hence from a security perspective they are vulnerabilities. Whether or not you, personally, trigger those vulnerabilities or not doesn't matter: the stack is vulnerable.

Note that you might choose to forbid anything that doesn't count as "modern C++", e.g. by enforced linting. Equivalently, you could instead have your compiler reject such programs (perhaps deciding to rip out various features and modules from the compiler, to avoid them being used). Either way, you're no longer writing C++: you're writing some other language (say, "C+++"), which is a sub-set of C++. In which case, you've done what the author suggested: deprecating C/C++ in favour of something safer!

Post reply on HN