Hacker News Reader

Comment by memracom | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com