News for hackers. Stuff that matters.
Re:Why C++ sucks (2016 edition) by fsloth on Monday February 22, 2016 @09:00AM (#11150793)
"I expect the companies that are starting new C++ projects today to be put out of business by competitors using better languages."

I don't think that's how software business works. I'm pretty confident there are niches out there where even COBOL would be a just fine implementation language if it provided end value for the user.

Domain understanding, network effects and marketing seem to trump bleeding edge most of the time.

That's not to say there are no situations where selecting a better language would lead to far better outcomes if there is time pressure and the language is viable choice with the technical constraints of the project. I'm just highly skeptical that this is a rule that works in general.

For an extreme example where this rule starts to look dubious, embedded systems - are there any better languages even available?

Re:Why C++ sucks (2016 edition) by lmm on Monday February 22, 2016 @09:22AM (#11150918)
Many embedded systems support Java or higher-level languages. OCaml might be an option; Ada or Rust certainly would be.
Re:Why C++ sucks (2016 edition) by BufordTJustice on Monday February 22, 2016 @11:13AM (#11151815)
The problem with all of these, with the exception of Rust and Ada, is that it's hard to do things like, get at pointers directly, for example. For all of the abstractions OCaml and Java bring, there is an often large performance penalty to pay, and when you're pass producing an embedded product, that's money you're leaving on the table because you're asking for more compute power than you actually need to get the job done. Ada is usually a pretty good choice, but it's hard to find developers outside of the defense industry; Rust on the other hand is often view (perhaps rightfully so) as still experimental and unproven.
Re:Why C++ sucks (2016 edition) by lmm on Monday February 22, 2016 @07:26PM (#11155486)
> For all of the abstractions OCaml and Java bring, there is an often large performance penalty to pay, and when you're pass producing an embedded product, that's money you're leaving on the table because you're asking for more compute power than you actually need to get the job done.

In my experience the performance differences are often grossly overestimated (particularly if you compare equivalent development times). And increased development time or higher defect rates aren't free. What you say is true for a particular niche, but I think that niche is pretty narrow (and in that niche I think the risks of Rust, while real, are smaller than the risks of C++).