Hacker News Reader

Comment by lmm | Hacker News Reader

That something is being done today doesn't imply that it needs to be done today.

I expect the companies that are starting new C++ projects today to be put out of business by competitors using better languages.

View on HN

"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?

Many embedded systems support Java or higher-level languages. OCaml might be an option; Ada or Rust certainly would be.

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.

> 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++).

Alternative explanation: things are done a certain way due to technical constraints and market forces which you don't know about or choose to deliberately ignore.

Entirely possible. But this is not "reality vs dogma"; it's one person's (or group of people's) judgement vs another.

At least in the storage space (which gets essentially no press on HN), I have come to the finding that the vast majority of core product codebases are C/C++. For the niche they fill, it seems really unlikely that even the still experimental Rust would replace them here.

Dropbox has re-written their storage layer in Rust https://www.reddit.com/r/programming/comments/3w8dgn/announc...

That said, they're the only one I know of, so your point still stands, generally.

Reply on news.ycombinator.com