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

811–820 of 929 posts

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

#811

Post by stouset »

gonzus wrote: post #651
ghoward wrote: post #470

Earlier quoted context omitted.

It's not lost on me at all. I prefer to finish software. [1] I get it to where it needs to be and put it in maintenance mode. I don't accept outside contributions. [2] I prefer to work alone to keep the scope of my software manageable and to reduce communication overhead. And to avoid working with people. People are too complicated. I obsessively document my software. [3] I comment all of my code. I wrote design docu…

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 we should stop using them when possible. Not "must". "Should". And further, I suspect he'd clarify that he is imploring this of the industry as a whole, and not at the scale of individual developers.

People still write asm, and nobody is coming for their heads. We need people like that! And we will need people who are skilled in C for the far foreseeable future. But the time has come where there exist alternatives to C and C++ which are superior for a very large bulk of their remaining use-cases. He's not scolding individual engineers who choose to continue writing code in a language he enjoys. He's calling for the industry as a whole to recognize this new reality and move forward with the times.

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

#812

Post by mustache_kimono »

mempko wrote: post #246

Compare Stepanov's brilliant design of the STL to Rust's current reworking of their 'binary search api'. https://github.com/rust-lang/libs-team/issues/81 Maybe 'memory safety' isn't the most important thing in this world. To me, writing software that does useful things in the simplest and most correct way is what matters. I get the feeling it's harder to understand my program's correctness with Rust (I mean algorithm…

> To me, writing software that does useful things in the simplest and most correct way is what matters.

Seems like a Rust sweet spot. Could you give another example? Here, it would seem this API proposal wasn't adopted because it wasn't fully baked. Isn't that a good thing?

Discussion re: Rust collections: https://doc.rust-lang.org/std/collections/index.html

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

#813

Post by pas »

LtWorf wrote: post #645
pas wrote: post #554

Earlier quoted context omitted.

Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison. https://github.com/tauri-apps/tauri uses OS provided WebView https://github.com/sciter-sdk/rust-sciter uses Sciter

> They mostly need stability and cross-platform support But Qt provides that… tauri has exactly 1 release, that was done 4 days ago. sciter has done no release in over a year, and has 6 releases total. It would be completely insane to pick either of those instead of Qt.

Fighting the problems of Qt bindings, Qt, Qt's build system to me is just not worth it.

If someone is a Qt and C++ expert, then maybe, but it still seems like an uphill battle compared to web stuff, which to me seems better supported on all platforms.

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

#814

Post by meragrin_ »

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?

C is not C++. While they strive for compatibility, I'm pretty sure there are cases where code compiled under a standards conforming C compiler will act differently under a standards conforming C++ compiler. Most C/C++ developers would compile a .cpp file with a C++ compiler if no other information was available.

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

#815

Post by userbinator »

dcow wrote: post #294
userbinator wrote: post #197

Earlier quoted context omitted.

His "opinion" is not only reflective, but amplifying, and that's the scary part. The companies are the ones pushing this "security" stuff, because they want to stop us from doing things like jailbreaking --- and eventually running any software they don't approve of. See https://news.ycombinator.com/item?id=32905587 He used to write very useful utilities which did things that Microsoft didn't officially support or oth…

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 OS-level stuff (and I'm glad that it isn't.)

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

#816

Post by stouset »

ghoward wrote: post #796
ModernMech wrote: post #776

Earlier quoted context omitted.

> You all have also implied that we are negligent for using C. I don't know about others, but I have not been. I’m sorry that people have implied that, but I feel most of the time when Rust people say languages like C should be retired or deprecated, are doing so because your skill and attention to detail does not scale. Maybe you personally have advanced enough to write safe code, and you have the requisite skills a…

> I’m sorry that people have implied that, but I feel most of the time when Rust people say languages like C should be retired or deprecated, are doing so because your skill and attention to detail does not scale. This is a fair argument. On the other hand, I wish we had less software so that attention to detail did not need to scale. For example, I run a Gentoo machine with the Awesome Window Manager and no systemd.…

> This industry grew too fast for its own good. It would have been better if it had had a master and apprentice model. The best programmers would be "masters" (in the sense of master and apprentice), and juniors would be apprentices who would write code under the master until the master thought them good enough to be journeymen (moving up from junior), and over time, such journeymen would themselves come to be recognized as masters, and the cycle would repeat.

I 1,000% agree with this perspective. I also actually suspect that some form of professional licensing and/or personal liability would benefit the industry greatly, in that it would give more power to engineers to decline to build software irresponsibly due to pressure from management. Obviously this would be wildly complicated and there would be (potentially intolerable) downsides, but I do wonder what things would look like if we could revoke the licenses of people who repeatedly exercise poor judgment, or if responsible engineers knew they had the backing of a professional organization when pushing back against management.

The irony isn't lost on me that elsewhere in this thread I said that nobody is coming after your software engineering license if you keep writing C :) And I do realize that would probably be a disastrous idea in practice. But in my mind it's great.

And while I do agree that the industry grew too fast for its own good, this is unfortunately the reality we live in. The need for software has exceeded both our ability to produce it reliably and our capacity for training qualified engineers. So we have countless junior developers writing production code without good mentors. And worse, I think we also have a terrifying number of "senior" engineers who are actually junior engineers with a lot of experience but trapped in a local maximum. I don't know how we fix this.

> By the way, the reason I don't use Rust is because I'm pretty sure I would actually write buggier code in Rust than in C. The reason for this is async/await: I just can't get it. I mean, I do get it, but the rules seem too complicated for my brain to do as safely as I can do threads and locks.

I "get" async/await but I… hate that it has to exist. I avoid it in all of my Rust projects. Partly because I don't want to use it, but also because I've never needed to solve a problem in a domain where it would have been invaluable. So just so you know, I've been writing Rust since right around 1.0 and I've been essentially able to just pretend it doesn't exist. I've never used it, but also I've never had to think about not using it if that makes sense.

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

#817

Post by userbinator »

shadowgovt wrote: post #209
userbinator wrote: post #197

Earlier quoted context omitted.

His "opinion" is not only reflective, but amplifying, and that's the scary part. The companies are the ones pushing this "security" stuff, because they want to stop us from doing things like jailbreaking --- and eventually running any software they don't approve of. See https://news.ycombinator.com/item?id=32905587 He used to write very useful utilities which did things that Microsoft didn't officially support or oth…

Perhaps his years of experience in the space have given him some perspective that leads him to a position other than the one we might have inferred from his previous work. I can tell you the way I felt about security and open architectures at 25 is very different from the way I feel about them now.

Years of being exposed to the corporate propaganda has had an effect on everyone.

I also feel very different now than I did 2-3 decades ago, because I realised the importance of freedom and how we are slowly losing it.

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

#818

Post by userbinator »

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…

Hell no! Have you read Stallman's Right To Read? Because that's exactly the dystopian vision it talks about.

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

#819

Post by ghoward »

stouset wrote: post #808
gavinhoward wrote: post #803

Earlier quoted context omitted.

> I really like C. I did actually spend about an hour reading his code. It's very nice, and I genuinely believe that Gavin is probably capable of writing memory-safe C most of the time. This is a nice compliment, thank you. > Except when his sanitizer setup is accidentally disabled, of course. Fair criticism. XD > I did find at least one case where a function in isolation is explicitly not memory-safe, but its safety…

> 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 invested the just time you've spent figuring out how to work around C's memory-safety shortcomings, your proficiency would be within spitting distance. But obviously those costs are already sunk.

I actually don't know. It's possible, even plausible, that you are correct.

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.

However, I might have been making progress and didn't realize it. Or maybe an epiphany like the one I experienced with Haskell would have been in the future.

Or maybe my brain just doesn't work in a compatible way with async models. I don't know.

It is one of my regrets that I did not try harder. Oh well; I guess I loved the visible progress of fewer and fewer crashes in a fuzzer more, even if it was slower.

> And at the end of the day, if you just love C and only want to write C then it doesn't matter what sorts of things another language provides.

As long as I am not negligent! I'll add more about this in a reply to another of your comments, though.

> I love C, but I've also come to love Rust. Sum types and exhaustive pattern matching are the sorts of things that are hard to live without once you've had them, and now languages that don't offer them are pretty much ruined for me.

I agree. I love them too, so much so that I run clang with -Weverything to get exhaustive matching in switch statements. And I emulate sum types with enums and unions. I always use switch statements to match on the enum value, which sort of gives me the experience of Rust sum types and exhaustive pattern matching. Sort of.

My language will have them for sure.

> But at the same time I'm not a fan of the async/await paradigm, though I begrudgingly understand why it was necessary and why it was designed the way it was. For now I simply avoid it, but it makes me sad that we were never able to find something better.

I agree. I'm sad about it too. I couldn't really reject Rust if it didn't have async/await, and I wish I didn't have to reject Rust.

(Though the RESF is still off-putting.)

I'm hoping that my language will be a competitor to Rust but allow people to try structured concurrency instead. If Rust still "wins," that's fine; people want async/await. But if they coexist or my language "wins," that's good too.

Eh, sorry for the long-winded comments.

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

#820

Post by ghoward »

stouset wrote: post #810
gavinhoward wrote: post #805

Earlier quoted context omitted.

> I'm sorry, but this is an entirely imagined persecution. Nobody is taking your C compiler away from you. Nobody thinks you're a bad person for using C. Nobody thinks you're a bad programmer for using C. I've had people say all of these things to me in various ways. "You should be ashamed of yourself," is a typical phrase used. > Many of us think there are better alternatives. We're excited about these better altern…

> "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 of putting it is that if I dropped you on stage in the middle of a RustConf keynote, nobody would actually have these types of opinions. And if anyone did express such a thing, there would be overwhelming opposition to it. But of course I can't prove this, and I'd be willing to admit I'm wrong.

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

Though dropping me of all people into a RustConf keynote would be a wild prank. Hilarious.

> And none of this discounts the fact that you've apparently seen these types of opinions firsthand.

Unless I've only seen personas, as you suspect, and I can't refute that.

> I don't think that's a reasonable take at all. I'd be willing to bet that what Mark Russinovich was saying was exactly what you just stated in another thread: "I agree with this. I never said people should use C by default; absolutely not. They should use Rust by default."

I'm not so sure because I used to be one of the people that thought C should die, as in, have everything rewritten into another language. People like that do exist.

But again, they may just be personas. Whoops.

> Being taken away is very, very different from other people not being sufficiently motivated to build something you want to exist. Nobody has "taken away" COBOL from folks by not porting compilers to arm64 (I have no idea if arm64 COBOL compilers exist, feel free to substitute a suitable arch/lang).

This is a fair counterargument. I guess I should correct myself by saying that it would feel like my C compiler would be taken away.

> I'd be willing to bet substantial sums of money that "eventually" will not include either of our lifetimes.

I'm not so sure, but no one can predict the future. :) I wouldn't have thought Rust would end up in the Linux kernel when I first heard of it. Now it's all but certain to happen.

> And my guess is it would be far less work to port C to (or write an LLVM backend for) x86-128 or aarch256 or RISC IX than to maintain your own language and keep it running on all the major platforms. But good luck to you nonetheless.

That's true. It's why my language will bootstrap itself to C99! For every platform that is too much work to support directly, I'll support it by having a C99 compiler for that platform.

C99 should not need much maintenance. I hope. Or someone else will care enough to do it. I hope.

> I'm pleased you pointed this out! I'd debated saying this but opted not to, it's great that we agree on that extra detail.

Good! And you're welcome.

Yeah, I'm picky. I've rewritten code given to me by a FreeBSD kernel developer who is twice my age and much better than me.

Post reply on HN