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

821–830 of 929 posts

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

#821

Post by einpoklum »

AtlasBarfed wrote: post #791
einpoklum wrote: post #342

Earlier quoted context omitted.

> "replace feature from n-5 years with the newer feature in the latest 0x00x release" Let me put a more pro-C++ spin on that sentiment. C++ is a language that's under long-term development. It might sound weird, but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized - and he had worked on it since the 1980s. With other languages, there's a lot of clearing-of-the-desk and s…

"but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized" So... let me ask you given this statement. Let's say there is an uber smart super productive programmer who states: I can rewrite the entirety of the ecosystem of one language in 1 year.... Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust? C++'s only real advantage in the current language marke…

> Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust?

Neither.

1. I wouldn't trust a person who says something like that. It takes a programming luminary several years to write a good (non-trivial, not-tiny) library the community can get behind, and even that usually involves iterations of use, feedback and partial rewriting/redesign.

2. Why would we want a "rewrite of the entire ecosystem" (whatever that ecosystem may be) all at once? That's a fiasco waiting to happen.

3. An "ecosystem" very often needs to be at least somewhat backwards-compatible, so I wouldn't want it written in something that's just out of the nylons.

Probably best to let that smart programmer write some decent foundational libraries which we can adopt one at a time, with increasing benefit of synergy.

> C++'s only real advantage in the current language marketplace is an installed library base

That seems untrue. C++ has various capabilities in different usage scenarios which other languages do not. But more importantly - programming languages don't all compete: They typically have different combinations of design goals. That's specifically true of C++ vs Rust.

> But how much of that is C++0x2020?

That doesn't matter much. For you, anything that's not written in the latest version of a language may be irrelevant/unusable. Not for the users of backwards (and forwards-) compatible languages like C, C++ and various others.

> Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions

No, 40 years of revisions is not a barrier to entry. Your saying that makes it sound like you are not very familiar with the language.

> mixed-in-C standard library, ye gods.

double x = sqrt(x_squared);

... oh, the humanity! Who would ever write something like this? It's a non-polymorphic function and its symbol doesn't get mangled! Ye gods!

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

#822

Post by nrvn »

hda2 wrote: post #316
lenkite wrote: post #260

Earlier quoted context omitted.

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

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…

Is there any process or policy for promoting third-party libs to standard library?

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

#823

Post by stouset »

ghoward wrote: post #819
stouset wrote: post #808

Earlier quoted context omitted.

> I've pushed commit e4b31620f181 to document that assumption, along with a note that assuming a non-empty string might be useful too. Nice! > By the way, `bc_parse_zero` and bc_parse_one` are constants, so I can make assumptions about them. This is why an empty string is fine: those constants do not have nul terminators at index 0, so if the string parameter does, the short-circuit operators will short-circuit. Ah,…

> Ah, of course. I knew that they were constants, but I didn't consider the short-circuiting of the comparison before indexing further into the string. No worries! That's why I specifically wrote it that way instead of a `strcmp()` call. I may be a little obsessive over getting my code right. > I hope you understand that—all snark aside—I truly, genuinely believe you. Thank you. > I do suspect that if you had investe…

> But I've spent gobs of time trying to understand async/await and failed. It wasn't as much time as I spent honing my C, but it was a lot. And I did not seem to make progress.

I've said this elsewhere but as a long-time Rust user I have literally never used or even encountered async/await. It exists, and I could use it if I needed to, but I never have nor have I had to spend effort avoiding it or thinking about it. It as far as I can tell a feature you can essentially entirely forget exists.

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

#824

Post by bowlerman »

jeff-davis wrote: post #737
bowlerman wrote: post #541

Earlier quoted context omitted.

Having a standard is overrated. What you usually want is clearly defined behavior and a good backwards compat story. Standards only make sense to me in the presence of multiple compilers or formal verification. There is ongoing work on supporting the second use case. I don't understand why people want multiple compilers.

"I don't understand why people want multiple compilers." Most people don't. But most development moved away from C/C++ before rust. If you want to call C & C++ "deprecated" you can't ignore the margins, which is exactly where those languages thrive. Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter.

> Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter.

In which case the issue is "Rust doesn't have a small compiler" or "Rust doesn't have an interpreter". Having multiple compilers won't necessarily mean that those issues are resolved. A more generic argument would be something like "the existing compiler doesn't cover my use cases".

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

#825

Post by dcow »

userbinator wrote: post #815
dcow wrote: post #294

Earlier quoted context omitted.

If you think memory-safe languages are some anti-jailbreaking/rooting conspiracy... well, have you heard of Java? No. Rust saves countless hours of frustration by eliminating frustratingly-hard-to-debug mistakes that humans commonly make when writing programs. Rust is pedantic, so you don't have to be. Rust saves companies money because Rust software requires noticeably less maintenance. Try it sometime. Don't worry,…

It's not just about jailbreaking or rooting. A lot of other user-hostilities can be defeated because something isn't quite as secure as it could be, and from that perspective, making things "more secure" is active hostility. "We are not truly free if we do not have the freedom to make mistakes." I guarantee that man will always be able to break what man can make Not with the rise of strong crypto. Java isn't used for…

Have you been paying attention? People are glitching chips now to read private keys out of hardware wallets and to bypass secure boot signature checks. And if that's not possible, then you chip the device and bypass its primary boot loader. Even with the rise of strong crypto people still find weaknesses. Your assertion about strong crypto defeating man's ability to break software simply isn't true. You must be from the thin period of history around 2008 for about 10 years where pwning your device had been predominately done in software.

Regardless, you certainly have a warped perception of security. My OS not behaving as it should because someone forgot to remove a pointer from a ring buffer after its data was freed thus allowing malware to compromise my hardware and my personal information--possibly my livelihood--just so you can jailbreak your phone easier is so insanely idiotic it's beyond me. The right solution, if you care about owning your hardware, is to buy a device where you're allowed to replace the secure-boot keys with your own so that you can participate in the advances in security that we've made over time. Or pass a law that requires companies that sell hardware to provide boot loader unlock keys similar to what we did with SIM cards.

Also, java has been used for embedded, real-time, and system level stuff. The Android system notably, ran Java when it was born. And likely so does your bank card.

There are ways to have secure programming languages and secure boot and also own your hardware without yelling at the clouds and wishing them rain 2008 back down on you...

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

#826

Post by stouset »

ghoward wrote: post #820
stouset wrote: post #810

Earlier quoted context omitted.

> "You should be ashamed of yourself," is a typical phrase used. I'm trying very hard to not "no true scotsman" myself here. But I tend to think of it like this: there's people, and then there's Twitter personas. There's a lot of very strong, absurd opinions that Twitter personas have but that I don't ever seem to encounter in the real world. Maybe another way of putting it is that if I dropped you on stage in the mi…

> I'm trying very hard to not "no true scotsman" myself here. But I tend to think of it like this: there's people, and then there's Twitter personas. There's a lot of very strong, absurd opinions that Twitter personas have but that I don't ever seem to encounter in the real world. If we expand that to Reddit and Hacker News, I have to agree, so it might have just been personas I went up against. > Maybe another way o…

> If we expand that to Reddit and Hacker News, I have to agree, so it might have just been personas I went up against.

"Twitter personas" is just my pet name for the phenomenon because it seems strongest (or maybe I just first noticed it) there.

> But I've never been to RustConf, so I can't dispute this. I'll simply have to trust you on this one.

Hah! I've never actually been either. I just meant this as a standin for putting you in front of actual, real, physical people who also are likely closer to the evangelist end of the spectrum.

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

#827

Post by einpoklum »

chriswarbo wrote: post #670
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++.

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 prog…

> All the old, problematic approaches are still valid code, and hence from a security perspective they are vulnerabilities.

So, you would mandate using Rust without "unsafe", then? Good luck with that.

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

#828

Post by kouteiheika »

gavinhoward wrote: post #806
kouteiheika wrote: post #797

Earlier quoted context omitted.

> But I'm still writing a language that is as safe as Rust that I will auto-translate my code into when it's done. Just curious, how do you intend to make it memory safe? By using a garbage collector, automatic reference counting, a borrow checker, or something else?

By structuring the language around RAII and structured concurrency. More details in my great-great-great-great-grandparent post. [1] tl;dr: If threads never exit before their descendants, and you only borrow an item in callees and in descendant threads, that would negate the need for a borrow a checker. As for sharing an item across threads and still not having data races, this will be done by implementing something…

Ah, sorry, my bad, I should have read the whole thread in detail first instead of just skimming it. (:

So do you also intend to completely disallow mutation? Because that's the only way I could see this matching Rust's safety guarantees without actually having a borrow checker.

Say, for example, that you allocate a new string, and you take a reference to it, and then you append to that string within the same scope. This triggers a reallocation which will make that reference invalid. To make that safe you'd either need to have a borrow checker (to be able to detect at compile time that the reference was invalidated), or you'd have to disallow mutation (the act of mutating wouldn't actually mutate that string, but create a new one, leaving the old one alone until it goes out of scope).

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

#829

Post by sudosysgen »

29athrowaway wrote: post #767
sudosysgen wrote: post #641

Earlier quoted context omitted.

You can say the same of any language. Deobfuscation is a hard problem. Only code meant to be reasonably understood is a valid comparison.

I don't mean obfuscation, I mean features of the language and their interactions. C++ is a mine field. You need to learn where all the mines are and spend your day carefully walking around them.

Sure, but that's not what you said. If what you meant is that there is no one that can read anh more or less reasonably written code in C++, then I believe you'd be wrong.

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

#830

Post by ninefathom »

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…

Update:

Based on the comments here, I see that I need to clarify two things, as edits are locked.

First, I actually happen to rather appreciate the Rust language itself. It is both powerful and pragmatic, and has quite a bit to recommend it. Even in situations where its addition has been personally very problematic for me (e.g. Firefox), I can still tip my hat to the added value. What I take strong exception to is Rust evangelism, i.e. the idea that Rust and its ecosystem are clearly superior to all other options in a given use case, and any person using other options must be either insane or uninformed. This represents, at best, a very narrow view of the computing ecosystem in the 21st century. My comment is a rebuke of the evangelism, not the language.

Second, the term "rusties" might have (reasonably) seemed like a label that I applied to any Rust developer. This is not the case, and the perception is a result of my failure to clarify. There is a particular class of person whom one meets, with whom any discussion of any technology project inevitably leads to "well you really should write that in Rust." Such folks- overzealous Rust evangelists- are "rusties" in my vocabulary. If that describes you, feel free to take insult if you like. If that doesn't describe you, then my apologies for any misunderstanding.

Post reply on HN