Hacker News Reader

Comment by jfaucett | Hacker News Reader

Basically I think it boils down to the fact that the c/cpp tooling is actually really sophisticated at this point and developers have already learned how to deal with the pain points of c/c++ so there is little incentive to change. Especially, since it means swapping out a highly advanced ecosystem i.e. UnrealEngine for the chance to spend the next 5 years building your own not-as-good system to then be able to start to program your own game. And its like this in every C/C++ industry I'm aware of (embedded devices / games / desktop apps).

I'm a rust fan, even more so of cargo (wish C/C++ had a cargo). But at the end of the day it almost always boils down to transition costs vs. benefits, and the benefits currently don't outweigh the transition costs IMHO.

View on HN

I think you are correct in regards to the people who are currently using C/C++. They already have done the hard work to make it usable for their systems. But newer developers will look at the complexity of C/C++ development and choose anything but.

Maybe it is like politics, rather than attacking your opponents you should offer something that they do not. Then you will build your own constituency and gain influence. It will take a long time, but if you keep on providing benefits to users, then attrition might take you to the top. When someone attacks your camp, ignore them. You do not need a better way to attack them, you just need to stick to the knitting and make your offer provide benefits to users. External forces will likely decide whether or not you overwhelm your opponents.

The problem with this approach is that you would really have to offer something groundbreaking to displace C and C++ while also matching portability (only matched by Java variants) and performance (often unmatched).

The about only languages that could compete right now are extended Ada for high assurance environments and Fortran variants for HPC. They are old but not dead and quite usable if you have the dollars to buy proprietary or invest time.

Microcontrollers and constrained environments are another critical niche for C and C++, especially given proprietary compilers.

Rust does not go far enough in safety to displace Ada (or Spark variant) while not offering improved performance and comparable portability with all the pains of a new language. It also does not do build once deploy everywhere stuff Java and JS attempt. Rust is neither here nor there. A good effort but not a solution.

> you would really have to offer something groundbreaking to displace C and C++ while also matching portability

If you offer something groundbreaking, you don't need to match portability. Many people will be willing to make the tradeoff.

> Microcontrollers and constrained environments are another critical niche for C and C++

Why do you assume Rust can't be used for these niches? I understand the potential issues with old environments, but what about modern/future ones?

> It also does not do build once deploy everywhere stuff Java and JS attempt.

Rust compiles to JS today. It will eventually compile to WebAssembly.

(It compiles to WebAssembly today too)

Interesting, but is there any advantage there over more dedicated languages?

If not, then again, Rust has no clear selling point. It really has to be better at something. Matching is not good enough.

It definitely is not easier to use nor embed. (To compete with the likes of Python, Ruby or Clojure.)

What is a "more dedicated language" in this respect? Your options are C, C++, or Rust. Same usual comparisons apply, I don't think wasm is particularly different enough of a situation to have any special advantages.

Not in the world. The options depend on a use case. For a website C++ and rust would be far down on the list. For a web server, even, there is a plenty of competition.

Similarly for an embedded scripting language or rapid prototyping.

I'd argue that safety is vital for web software, so Rust is a candidate for "the best language" for web servers. The same is true for security libraries.

Or how about the original purpose of Rust, to rewrite a rendering engine? That's an incredibly widely used platform.

There's an OS being written in Rust that a lot of people are really excited about. There are very few languages other than C/C++ that are actually viable for rewriting an OS and would, in and of themselves, prevent entire classes of bugs.

> For a website C++ and rust would be far down on the list.

This thread is about WebAssembly. For that, those are your only options currently.

> easier to use nor embed

"Easy" has no objective definition. Does it mean "getting code to run"? Or does it mean "writing bug-free code"?

For me, easy means the latter. It means that human error is harder to introduce into the code. A great language should not rely on the shaky pillars of discipline or expertise, because neither of those are easy to find or enforce, nor are they consistent. A disciplined expert might be too sleepy to write safe code, for example.

Rust is much easier to use than C and C++ because the compiler helps you so much and replaces discipline/expertise. That's the whole point. Rust prevents you from doing something you don't intend to do (or at least it does it better than most languages).

Python, Ruby, and Clojure don't have the same guarantees, and none of them can be used without garbage collection, making them unsuitable for a variety of cases where Rust can be used.

Compiler does not help you. It is not a proof suggestion system like Isabelle/HOL or the like.

In fact error messages rust produces rival the terrible nature of ones in older C++ compilers thus far.

The compiler only prevents you from making mistakes. Intentions do not even enter into it. See, some of the performance critical code in our apps has to work around even the lax C++11 rules. It is completely impossible in rust without using unsafe stuff liberally - specifically gets about 1000x slower and this matters a lot. Compilers know nothing about intentions, nor can a borrow checker enforce intentions unlike a type system.

> Compiler does not help you. It is not a proof suggestion system like Isabelle/HOL or the like

This seems like a gratuitous misrepresentation. A compiler does not need a proof suggestion system to help you.

> In fact error messages rust produces rival the terrible nature of ones in older C++ compilers thus far.

No, it doesn't. The error messages are wonderful and constantly improving.

> It is completely impossible in rust without using unsafe stuff liberally - specifically gets about 1000x slower and this matters a lot.

Can you give specific concrete examples?

You only need a some major players and big names to get behind rust and I would bet it would surpass C/C++ code-base within a couple of years. It wouldn't replace major frameworks or libraries written in C/C++ but I it wouldn't take much work to write the wrappers around them anyway.

While such support might be helpful, the majority of systems in C++ that I've seen are significantly larger than the libraries they are consuming. In other words, such library wrappers are but a scratch on the surface of the system.

I often wonder - how big does a code base have to be before an advocate of these ideas (ie: "rewrite it in X cause X is abstractly better") might be inclined to backpedal and reconsider their advocacy?

I found working with Operation Flashpoint/VBS2/Arma 2 that the code base being so large and so many edge case conditions that it will never re-written.

One example from the VBS2/Armed Assault 1/2 they replaced the way arrays references are handled. Previously array's assignment was a copy. They changed it so array's assignments would mirror java's references and only the pointer to the buffer would be copied eg.. copy on write. They had so many idiotic edge case conditions that they reverted back to the old method.

So when I say they just need some major backers it would be for new system and applications that would take advantage of the new language. Re-writing most game engines today doesn't have a strong business case. Writing new games/software and shipping faster is more important.

Reply on news.ycombinator.com