Hacker News Reader

Comment by dagmx | Hacker News Reader

I've only ever really seen it in Zig communities that Rust is closer to C++

In Rust communities, it's often pitched as alternates to both, but closer to C.

I suppose it's all relative, but the comparison of rust to c++ seems external

I think it is a C++ replacement that is _closer_ to C. It has generics, traits, RAII, etc, which are C++, not C, features but the way that Rust implements them _feels_ closer to C. I don't know if this quite makes sense but as an external observer this is my impression.

I don't really understand how Rust could be compared to C. Rust is perhaps more austere than C++, but that's like saying the neptune is smaller than jupiter. It's still a big language with a generous standard library. You almost never do everything yourself, by hand, which is the hallmark of the C experience. Just compare the list of methods rust has for a &str, compared to the fact C doesn't have a string type, to see the gulf of cultural difference.

Obviously, C and Rust are both low-level languages (in terms of control and overhead), but there are quite a few of those.

Yes, I also had the impression Rust is a C replacement.

From a programming language design space, it's much more like C++.

However it can occupy some niches that C can but C++ does poorly because of zero cost abstractions, I think.

(Very handwavy)

There are no niches where Rust can do better than C++. In many places Rust can, uniquely, match C++.

De gustibus non est disputandum, and thus at such a high level of abstraction you are at best trolling.

The first person to mention trolling is invariably the troll.

This is of course false.

I assure you there really are places where Rust can match C++.

Yes, but that's the sensible part of your comment, not the part I was obviously disagreeing with. (And no, the troll is not the one who first uses the word.)

Rust's purpose, its whole reason to exist, is to displace C. Rust will unavoidably fail in that, because anybody still using C is not willing to learn anything else: anybody willing to move on from C already did, long ago.

Rust is already approaching C++ in complexity, surpassing it in some places; and also in expressive power, but not surpassing it anywhere yet.

If Rust does not end up fizzling (which is still very possible!), Rust programmers will generally be drawn from the same population as C++ programmers. They will be people who want and can use a powerful language to make themselves more productive and able to manage bigger projects, without need to worry that they are taking a performance penalty, or losing control of details that matter.

Users of Zig, like of Nim and C, will be those uncomfortable with language power, disinclined to automate. Their attention is not on software and what they can build of it, but on problems where a thin veneer of software can add something useful. When there is not much for the software to do, you don't need much power to get it doing that.

Very minor correction - Nim tends to attract people specifically with its language power via its powerful Lisp-like metaprogramming facilities, static introspection, etc. These features are expressly there to automate away mundane repetition. I do not think it belongs in a list with Zig & C the way you use it here.

I also think users of C (not sure about Zig) are quite happy to automate things. Linus Torvalds is a big user of C. He wrote a little C-like compiler to check Linux kernel code called Sparse [1]. You seem to be trying to discuss maybe larger (but not very well articulated) subpopulations of "Users" than Apex Programmers like Linus. It is definitely easier to do this with C than giant languages like C++.

Why, the 1980s & 1990s were littered with maybe dozens of hacked C compilers doing "this or that" automation in a way you do not see for C++ (and will probably never see for Rust). In point of fact, C++ itself (C with classes) was an early example of such! The idea was to automate/codify the object-oriented style of Simula in C.

pjmlp's sibling & child comments are also some good color on the history/context of all this. { Of course, partly it all depends on what you meant by "language power" and "automate" - I am just going by what that seemed like. }

[1] https://sparse.docs.kernel.org/en/latest/

"Littered" is the operative word: who today uses any of them? (Maybe lex and yacc.) In the 80s and 90s, viable alternatives to C were thin on the ground, so the population demographic of C coders (which included myself) differed markedly from today. That hardly any are used today tells us about the inclinations of the long tail of remaining hold-out C coders.

Even if the only success story for Rust would be mainstream adoption of lifetime checkers across languages to some extent, that would already be a victory as it managed to change the baseline of language design across the industry.

A subject that now has become even regular presence at C++ conferences and considered a must have in static analysers roadmap by all major vendors.

Rust might fizzle out in a decade, and still leave such a mark in the industry.

I have not heard of a lifetime checker in any other language, except maybe Midori.

So here is a sample,

Chapel, HPC language mostly sponsored by Intel and HPC

https://chapel-lang.org/

D programming language,

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Ada/SPARK,

https://docs.adacore.com/spark2014-docs/html/ug/en/source/la...

Swift,

https://github.com/apple/swift/blob/main/docs/OwnershipManif...

ParaSail

http://www.parasail-lang.org/

Project Verona from Microsoft Research

https://www.microsoft.com/en-us/research/project/project-ver...

Project Snowflake from Microsoft Research

https://www.microsoft.com/en-us/research/publication/project...

And finally your favourite C++

"Implementing the C++ Core Guidelines’ Lifetime Safety Profile in Clang"

https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...

Also the "Clang Static Analyzer - A Tryst with Smart Pointers" talk at 2021 LLVM Developers Meeting.

For the Visual C++ part of the story

https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

And GCC as well, although they are late to the party

https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer

Finally a couple of CppCon 2021 talks that touch on the subject in various ways,

Type-and-resource safety in modern C++

Code Analysis++

Static Analysis and Program Safety in C++: Making it Real

Finding Bugs Using Path-Sensitive Static Analysis

> Chapel, HPC language mostly sponsored by Intel and HPC

Minor correction: Intel hasn't traditionally been a sponsor of Chapel (though we'd love to see that change). Chapel was pioneered at Cray Inc. and continues on even stronger at HPE after its acquisition of Cray.

-Brad

Thanks for the correction, I thought seeing them referenced in some talks.

All the best.

At least most of these don't seem to be added language features, but separate "static analyzers" that rely on inference from existing language structures.

Sounds like a lot of "contemporary automation today" to me - automation that would often apply about as well to C code bases as well as horrifically overcomplex C++ codebases.

Also, why even draw a stark contrast between "a language" and "its tooling"? As a dev, you get to use both.

What is even the line..? Almost every compiler for anything provides options. Does gcc -fsanitize=.. not count because it's not "standardized" or only because its not activated in "typical" deployments like Rust integer overflow checks?

The line is very, very easy: if it is in the language, you can see it represented syntactically in the source code, and programmers using the language write it there. If not, not.

Clang and Visual C++ static analysis tooling can be represented on the source code via C++ attributes and blessed library types, so...

So... not in the language, but in proprietary, non-portable extensions.

With exception of C++, they certainly aren't.

C++ type system is impossible to fix while keeping backwards compatibility, so static analysis tooling is the only possible solution.

I sort of look at it as aiming at the spot where you could write the code in C with a sprinkle of C++ features and whether to add that sprinkle or do things like hand-rolling a vtable system where you need one is a decision that will vary depending on circumstances.

Though I believe the mozilla code it's replaced was all -very- C++.

Reply on news.ycombinator.com