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

911–920 of 929 posts

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

#911

Post by ncmncm »

cercatrova wrote: post #894
ncmncm wrote: post #891

Earlier quoted context omitted.

Try to explain the difference between "no new projects" and "no programs". Any program I have not written yet would be a new project. Any old project is one where the program has already been written. So you are being dishonest in pretending to a distinction without a difference. Switching from the legitimate "you should use my new language because it is good" to "you should demote everybody coding to legacy maintena…

> Any program I have not written yet would be a new project. Any old project is one where the program has already been written. That is simply not any definition I've ever heard for a new project. You are assuming a binary of written or not written, and yet there are codebases that are incompletely written. That is what the parent means about ongoing projects that wouldn't migrate to Rust where you'd still be able to…

You have already revealed your true colors.

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

#912

Post by cercatrova »

ncmncm wrote: post #911
cercatrova wrote: post #894

Earlier quoted context omitted.

> Any program I have not written yet would be a new project. Any old project is one where the program has already been written. That is simply not any definition I've ever heard for a new project. You are assuming a binary of written or not written, and yet there are codebases that are incompletely written. That is what the parent means about ongoing projects that wouldn't migrate to Rust where you'd still be able to…

You have already revealed your true colors.

No, more like you have, as others have pointed out.

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

#913

Post by felipellrocha »

ekianjo wrote: post #192
woodruffw wrote: post #11

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals

Appeal to authority?

It’s only a falacy if the authority is not an expert in the field they’re speaking about. Example, a religious leader speaking about science matters, or an accountant speaking about engineering matters.

Otherwise, the argument is 100% valid.

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

#914

Post by ssokolow »

namelessoracle wrote: post #801
supportlocal4h wrote: post #693

Earlier quoted context omitted.

Or, the commander thinks that in an age of drones and cruise missles, bayonet charges don't make sense even if the bayonet is now attached to a machine gun.

And then the commander goes all in on that strategy, enemies knock out communication networks / find a drone counter measure, and now enemies have a decided advantages because they kept bayonets on their machine guns.

Aren't soldiers typically issued submachine guns? (That's what SMG is short for, isn't it?)

I think they might have been going for the ludicrous image of sticking a bayonette onto the front of a fixed gun emplacement.

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

#915

Post by ssokolow »

rat87 wrote: post #851
svnpenn wrote: post #657

Earlier quoted context omitted.

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

Generally rust prefers to keep things out of the standard library because it's hard to change/improve a standard library. They try to give enough useful stuff and then leave all the other stuff to easily downloadable packages.

More importantly, it means that version upgrades are decoupled.

They don't have to download and install version 1 of an API for backwards compatibility if you're on version 2, and you don't have to download a new compiler version to upgrade a package as long as the package's maintainer is still willing to support the version you're on.

(That latter one being the same as with support for new revisions of C or C++ in in GCC.)

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

#916

Post by ssokolow »

snovv_crash wrote: post #326
woodruffw wrote: post #219

Earlier quoted context omitted.

> Wanting to weaken the economic position of a certain type of developer makes a lot more sense. Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration). These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "…

> we're seeing more and more clients take memory safety seriously Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.

I'm reminded of this quote, written in support of more and stronger use of systems for formal verification, like powerful type systems:

> Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. -- Edsger W. Dijkstra, "The Humble Programmer" (1972)

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

#917

Post by ssokolow »

_gabe_ wrote: post #770
slashdev wrote: post #722

Earlier quoted context omitted.

I think I hit a nerve with this one. If you put out a job ad for any mainstream language (Java, JavaScript, C++, among others) you're inundated by applicants who have no business even working in this industry. If you put an esoteric language like Elixir or Rust, you get a smaller but much higher quality pool of applicants. That's my personal experience, I don't have hard data to back it up. Paul Graham once wrote abo…

> I think I hit a nerve with this one. It does tend to grate on people when you have developers from a certain community going and calling anybody that doesn't agree with their "One True Way" inferior and not loving their craft. This is literally the No True Scotsman fallacy to a tee. You're essentially saying, "Only a true programmer that loves their craft would use Rust. Clearly if you're not using Rust, you're not…

It sounded like they were saying "both pools have a lot of qualified applicants, but C++ has incentives to draw an additional flood of un/under-qualified applicants that haven't started to apply to Rust yet".

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

#918

Post by peatfreak »

planede wrote: post #720
peatfreak wrote: post #550

Earlier quoted context omitted.

Can you please elaborate?

I was being sarcastic. I find the assertion that modern C++ is a scam hilarious. It doesn't make any sense. Who benefits from this scam? Who are the victims? The sentence is indeed from a meme template[1], but I thought that my comment would stand on its own. https://knowyourmeme.com/memes/stop-doing-math

Thanks for elaborating. I've been hearing all sorts of criticisms of C++ ever since the 1990's (!!!) but I've been out of the loop for a little while and maybe need some catching up.

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

#919

Post by pas »

LtWorf wrote: post #833
pas wrote: post #813

Earlier quoted context omitted.

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.

If you can use webstuff, clearly it wasn't a problem that involved c++ or rust in any way.

... why?

Using a cross-platform backend + UI stack seems like a best of both worlds. ~5 years ago we developed a kiosk for car washes (you could buy a membership online, then use the QR code, but it had also devices to accept coins and banknotes), backend was Rust, frontend was Angular (the kiosk ran Firefox kiosk on a touch screen, and there was even a tablet at the counter that ran an app that was a bundled webview basically).

It worked well on different devices in different sizes, updates were as simple as "yes restart the thing".

Interestingly we had a C++ project shortly before that (number crunching for music recognition, so not really something that you'd do without a high performance language). We picked Rust for the next one because it seemed easier to implement the state machine required to manage the connected devices & clients in it than in Python.

I absolutely don't miss C++ or Qt (or PyQt, or MOS files, CMakeLists.txt shudder)

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

#920

Post by sylware »

steveklabnik wrote: post #758
sylware wrote: post #646

Earlier quoted context omitted.

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.

the syntax implicit expensive free is the same issue than the syntax implicit expensive allocation. I clearly recall when I read early rust specs that I did not want that (and more).

Additionally, I wonder if they fixed the other C issues, namely removing integer promotion, implicit casts (but different explicit casts for compile-time and runtime), enum, _generic, typeof, 1 loop keyword is enough, no switch, goto is not harmful, have only sized primitive types, change extern/static... Hopefully, rust does not have object-orientation.

And you can bet, you will find a bunch of sickos not writting simple and core rust for linux... but rust with tons of extensions only in 1 or 2 compilers like the "C" from linux which is actually the C from gcc and nothing else (clang and icc playing catchup).

I should re-read the language syntax specs though. But I guess, I would drop that reading if I encounter a definitive nono again.

Post reply on HN