Live data from Hacker News

Criticizing the Rust Language, and Why C/C++ Will Never Die

viva64.com

71–80 of 89 posts

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#71
post #70

Earlier quoted context omitted.

&mut pointers ensure that they are the _only_ reachable alias to a given bit of memory.

So, it's functionally equivalent to a "restrict" keyword in unsafe mode? (i.e. you can alias without the compiler being able to prove it as if you weren't aliasing.)

My C is a bit Rusty, so I'll say that they follow http://llvm.org/docs/LangRef.html#noalias which says

    > Note that this definition of noalias is intentionally similar to the
    > definition of restrict in C99 for function arguments.
I'm not sure if they just mean 'similar' or if it's actually exact.

If you alias, you might break, as optimizations will assume otherwise.

Oh, and `&mut` pointers are safe to use, not unsafe.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#72
post #4

I note that there are no arguments that C/C++ is better than Rust, except that it has been used for longer (and thus has more tools & knowhow around it).

That C/C++ have a formal standard and have an entire tool ecosystem is a huge advantage over Rust for mission critical and safety critical areas (not that Rust would be used for SC applications).

That formal standard also leaves huge swathes of code undefined. Not exactly what you want for "safety critical areas".

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#74
post #73

What did everybody make of the benchmarks cited in the article? I couldn't really understand what they actually represented, or if I should put much stock in them. I was surprised that Rust didn't come out better in those.

A bunch of changes landed right before the beta release some weeks back, and a bunch of examples broke. We also haven't invested much time in making sure that the examples have kept up lately. We used to beat C++ in several of them, but who knows what's happened since.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#76
post #64

I left a comment on Reddit that I'll adapt here. It's really intended at the Rust community specifically, but I think the message is still worthwhile anyway: Not everyone is going to like Rust. That's totally okay. I've seen language communities, especially newer ones where people are particularly passionate, essentially turn into... this is a bit strong, but mini-cults. Where if you don't like the language, you're o…

I've been programming for 35 years, and I remember when object-oriented programming advocates seemed cult-like. As it turned out, O-O is a very useful tool, but it is not the ultimate programming paradigm. Time has shown that the early adopters of O-O were mostly justified in their enthusiasm, but tended to overstate the benefits of the technology. The O-O naysayers had concerns about performance, which is an issue i…

> Today, I see similar reactions to leading edge technologies and languages that are difficult to understand, whether they be FP, Rust, or Haskell.

I wouldn't lump all three together just because they may happen to be somewhat difficult to understand. I see your point regarding FP (and Haskell happens to be an FP language). However, Rust is a multi-paradigm language, just the way C++ is. Time and time again in my day job, I see issues in our code that Rust would have prevented at compile time (and we're not using C++).

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#77

>OK, but doesn't it imply that I do not need Rust at all because I could write 90% of my code in Go and the rest 10% in C? Only silver bullet seekers and airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented about having 100% of a program written in seemingly one language. Have you actually tried to do that or understand what Rust unsafe code means ? Interfacing between different run-times an…

There's a lot of the "write X% in slowlang and (100-X)% in fastlang" thrown around, but I have to say, I've not seen too many such projects around.

IMO most python works this way in reality. For example the yaml module is calling out to libyaml and most heavy lifting modules are the same.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#78

Earlier quoted context omitted.

That C/C++ have a formal standard and have an entire tool ecosystem is a huge advantage over Rust for mission critical and safety critical areas (not that Rust would be used for SC applications).

C++ is impossible to validate formally. Rust inherently guarantees static memory safety in many situations, on the other hand.

     C++ is impossible to validate formally.
This is incorrect. Any language with a well-defined semantics (such as a compiler or interpreter) can be validated formally. It may just be too time-consuming for people to bother. For example the operational semantics of C has been implemented formally, e.g. [1]. The same could be done with C++.

[1] http://fsl.cs.illinois.edu/index.php/An_Executable_Formal_Se...

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#79
post #10

Earlier quoted context omitted.

A formal standard that has undefined behavior and is apparently difficult to implement a compiler for. It seems C++ is popular for mission critical software despite its standards.

You have to be a little smart about C++. Avoid using anything dynamic (including exceptions, dynamic casting, etc).

A funny statement considering how the author was lamenting the lack of exceptions in Rust :)

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#80
post #45

I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion. the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, fr…

At this point, the only response needed to "rust is slow" claims is - rustc is beta. Come back when it's cooked :)

Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster.

The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use.

(Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)

Post reply on HN