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

511–520 of 929 posts

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

#511

Post by ookdatnog »

scoutt wrote: post #487
hansjorg wrote: post #478

Earlier quoted context omitted.

Not all Rust programs are thin layers around libraries like FFMPEG. Why would you assume that? Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

> Why would you assume that? It might not be using FFMPEG, but gdi32.dll, winsock2.dll, libc, etc. Correct? Unless you run on 100% bare-metal, the "safe" code is still a tiny fraction. What if my linked C library returns an invalid pointer? Rust will still make the assumption it might be valid and play along. (that might be the reason why Rust likes to compile libraries/dependencies from source) > Also, "if it can't…

The code in those libraries has been run billions upon billions of times, by billions of people. Sure, the libraries are written in unsafe languages, but they are incredibly battle-tested. Depending on your perspective, this may or may not be as good as a formal guarantee of correctness; at the very least there is a strong probabilistic argument for their correctness and safety.

The 1% of code that is your own will, upon creation, have been run precisely zero times, so there is no probabilistic argument to be made for its correctness. Safe languages let you exclude entire categories of mistakes even when your code hasn't been run yet, which seems obviously valuable.

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

#512

Post by hansjorg »

scoutt wrote: post #487
hansjorg wrote: post #478

Earlier quoted context omitted.

Not all Rust programs are thin layers around libraries like FFMPEG. Why would you assume that? Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

> Why would you assume that? It might not be using FFMPEG, but gdi32.dll, winsock2.dll, libc, etc. Correct? Unless you run on 100% bare-metal, the "safe" code is still a tiny fraction. What if my linked C library returns an invalid pointer? Rust will still make the assumption it might be valid and play along. (that might be the reason why Rust likes to compile libraries/dependencies from source) > Also, "if it can't…

> "encapsulate the unsafe code in a data structure library with a safe interface"

This was referring to using unsafe data structures in Rust by pulling in a Rust library so that your application code doesn't need any unsafe blocks itself. This is a huge win for your application code, even if there's other code that is still "unsafe".

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

#513

Post by cercatrova »

noobermin wrote: post #213
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.…

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT…

Surely you're joking, because I simply refuse to believe that you think Rust developers are actually sitting around thinking how to put other devs out of a job instead of, you know, using Rust simply because it's a better, more well designed language.

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

#514

Post by kubb »

ncmncm wrote: post #400
Ar-Curunir wrote: post #261

Earlier quoted context omitted.

No Rust Evangelist is out there thinking, "Hm, how do I put C/C++ developers out of business today"

I see you do not have much contact with Rust evangelists.

What issue is there for the C++ developers to transition?

Rust is a simpler language, with better characteristics. Memory safety is the a big selling point for the business people, but there is also a better module system, dependency management, better generics, no hidden memory allocation, etc. etc.

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

#516

Post by gpderetta »

ReactiveJelly wrote: post #204
tdeck wrote: post #148

Earlier quoted context omitted.

Are new devs less likely to screw things up in Rust? Probably. Is a modern Rust codebase easier to onboard with than a 40 year old monstrosity of a Microsoft C++ codebase? You bet! Are more people excited about learning Rust? Probably. Is rust much faster to learn than C++? Call me a skeptic. I've written Rust professionally and would rather write Rust than C++. That said, almost every concept you need to understand…

Well, our C++ codebase has a lot of threads that talk a lot, and buffers we'd rather not copy. Plus ad-hoc NIH versions of stuff that exists in Rust's stdlib, like mpsc, or ad-hoc NIH versions of popular crates, like for logging. I sometimes just wish I could punt to Tokio. Why am I managing threads? Threads are an implementation detail! I see it as, Rust tells you about the complexity and helps you with it. C++ wait…

I think that the C++ version of Tokio is ASIO (either its boost or standalone variant). Neither is in the standard library. 20 Years ago it would have been ACE.

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

#517

Post by aspyct »

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

What's wrong with .cpp extension?

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

#518

Post by adrift »

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

Modern C++ is a scam.

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

#519

Post by perlgeek »

pizza234 wrote: post #506
hda2 wrote: post #316

Earlier quoted context omitted.

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anythi…

This is a tricky subject. Rust being a low-level library, adding something means inherently choosing a preferred approach to a problem rather than another, which may be disagreeble. The consequence is that there would be still the sub-sub-dependencies problem, because the author of a crate may decide that the stdlib implementation is not appropriate for the use-case (Rust is low-level; low-level development is typica…

Clearly different people have different needs.

Having two distinct "products" could help here. There could be a "bare rust" that is minimal and unopinionated, and used by those that need a small footprint, for example. A "battery included rust" could have common solutions to common problems that are hard to solve with "bare rust", at the expense of making choices that are best avoided for "bare rust".

My current outsider's perspective is that there's some kind of ever-shifting, never quite established consensus on which batteries to include, which tends to make it harder than necessary to switch project, interoperate between libraries etc.

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

#520

Post by dale_glass »

aspyct wrote: post #517
zerr wrote: post #503

Earlier quoted context omitted.

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

What's wrong with .cpp extension?

The implication is that he's mostly writing C despite the file extension suggesting they contain C++.

C++ changed a lot over time, and the way modern code is supposed to be written is very distinct from "C with classes", but you still can do that if you want.

Post reply on HN