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

751–760 of 929 posts

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

#751

Post by ghoward »

stouset wrote: post #489
Arnavion wrote: post #477

Earlier quoted context omitted.

>Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge…

> Tell me what subset of the repo named "bc" you consider to be "the program" Clearly, the parts where you aren't able to find memory bugs.

Anything built without the -a option to configure.sh. You can try the library too, but I did mess up that one time that you already know about.

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

#752

Post by kweingar »

svnpenn wrote: post #662
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

Isn’t the whole shtick with programming language devotees that they have names for themselves like Rusties and Gophers and whatnot

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

#753

Post by bitL »

stormbrew wrote: post #273
bitL wrote: post #256

Earlier quoted context omitted.

Sure, but don't forget the inherent trade-off - Rust allows you to write safer code at the cost of getting in the way. It simplifies some things and makes other things very complex. It empowers average devs that can suddenly write certain types of system services easily and be reasonably sure they work as intended, but it gets in the way of advanced devs writing core systems.

This sounds an awful lot like how everyone thinks they're an exceptional driver and everyone else is bad. Reality is no one's actually that great at piloting a ton of metal at speeds their brains can't keep up with in an uncontrolled environment. Anyways, unsafe exists so that if rust is genuinely in your way you can still do what you need to do.

Even C++ requires inline/linked assembler code in certain system cases to squeeze out maximum performance - why would you think Rust is an exception? It has nothing to do with elitism.

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

#754

Post by Narann »

hgs3 wrote: post #211

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…

unsafe is the feature you need.

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

#755

Post by ghoward »

mustache_kimono wrote: post #735
gonzus wrote: post #651

Earlier quoted context omitted.

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…

You do you. Maybe it isn't said often enough, but each side (Rust-lovers and Rust-haters) has to be confident enough to allow others to disagree. However, let's be serious, the anti-Rust crowd has not been some bastion of high-minded virtue with its flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..."), mole hill matters of taste ("Egads! The syntax!"), drive by hype hate, and u…

Because it is. And it is because you all say things that imply people like me are terrible, awful, evil, no-good, very bad people for not using Rust.

We are not. We just have different preferences.

You all have also implied that we are negligent for using C. I don't know about others, but I have not been.

That's why I have the challenge to break a release of my `bc`. I actually have not been negligent because I do put in the effort required to eliminate memory bugs as much as possible.

Until the RESF refrains from implying we are bad or negligent for not using Rust, we will be resentful.

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

#756

Post by svnpenn »

kweingar wrote: post #752
svnpenn wrote: post #662

Earlier quoted context omitted.

> Rusties please don't

Isn’t the whole shtick with programming language devotees that they have names for themselves like Rusties and Gophers and whatnot

I use both of those, and I would just say "I use Rust and Go". I don't think "Rusties" is appropriate, unless you are 13 years old.

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

#757

Post by slashdev »

krona wrote: post #578
slashdev wrote: post #549

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

> The language is simpler, cleaner, safer, and more enjoyable to work with. I was a Rust v1 contributor. I have great hopes for the language as a replacement for c in systems engineering. However, I much prefer C++ 20 for the kind of work I do (scientific computing). Rust isn't a competitor to C++ in that arena, in my humble opinion. > Programmers currently using Rust are superior to programmers using C++, statistica…

> I was a Rust v1 contributor. I have great hopes for the language as a replacement for c in systems engineering. However, I much prefer C++ 20 for the kind of work I do (scientific computing). Rust isn't a competitor to C++ in that arena, in my humble opinion.

There's a lot of domains where Rust isn't an appropriate replacement. Notice I phrased it as "if you have the choice between Rust and C++". Often times because of libraries/frameworks you need, that may not really be a choice.

> The phrase 'statistically speaking' suggests the collection of empirical data. Could you elaborate?

I don't have data apart from two decades of screening candidates and conducting interviews. I've heard this from other people, including Paul Graham, and I've seen it in my personal experience. I probably should have chosen different wording to not mislead people that this is backed by hard data.

> If Rust becomes popular enough, this will no longer be any truer than for people who learn c++.

That's how it goes. Python was once a signal for finding better developers. That's no longer true.

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

#758

Post by steveklabnik »

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.

There is no syntax that allocates in Rust. This was one of Linus' big reasons for accepting it into Linux.

Functions can call malloc or equivalent, and while constructors don't exist, destructors do, so you can call free in them.

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

#759

Post by mustache_kimono »

svnpenn wrote: post #657
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.

Yeah. FFS, they don't even have a JSON parser in the standard library...

As a Rust user, I have to say I think this is the right choice. Keep things out until they are practically dead/done. Rust covers a very large number of language use cases from C++ to Python. C++ doesn't have a std lib JSON parser either. And serde is fantastic!

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

#760

Post by ghoward »

alkonaut wrote: post #721
ghoward wrote: post #135

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

> Oh, and it's possible to make C as good as Rust: I've got macros to do automatic bounds checking. The really tricky macro though comes when you want to check races in shared mutable state...

No macros. This is one spot where Rust is better than C. (Though it is too limiting for my taste.)

Instead, I use ThreadSanitizer and add locks where I may not even need them. Then I may remove some, or change them to different synchronization primitives, and between every change, run TSan several hundred of thousands of times to tease out any race conditions. It's my way of fuzzing for race conditions.

Post reply on HN