Hacker News Reader

Comment by d33 | Hacker News Reader

Why would anyone choose C when Rust becomes mature?

Rust is much harder to learn than C. Rust is a good language, but, like C++, it has several levels of abstraction that C does not.

With C++, the template fans took over the language and overcomplicated it. Now you can't do anything in C++ without some template library. Even C++ enthusiasts admit that template programming is hard. It may even be a specialist skill that most C++ programmers do not have.

Rust picks up where C++ leaves off in that area. There's so much going on under the hood in templates that programmers are pushed into a ritual/taboo style of programming. (That's where you're taught to do something a certain way, but may not know why.)

It's really hard to kill off C.

Rust is much harder to learn than C. Rust is a good language, but, like C++, it has several levels of abstraction that C does not.

I don't agree with this; using this logic, I would arrive to the conclusion that C is much harder to learn than assembly, as it has several levels of abstraction that assembly does not.

> It's really hard to kill off C.

While I totally agree with C's longevity, Rust has something special going on.

You know that long bets website? I'd be happy to place a ten year bet with someone that Rust starts taking a big slice of C's pie. For kernel development, embedded systems, you name it. I'd be happy to qualify my bet with metrics based assertions, too.

It seems highly unlikely to me that Rust would take over true embedded systems (i.e. EEPROM, no OS, etc.), simply because nobody is going to write a Rust compiler for their custom architecture.

The resource constraints are what make C essentially the optimal solution for those applications

Note that you just need to write an LLVM backend for this, not a full fledged Rust compiler. LLVM IR is somewhere between C and assembly so it should be about as hard as writing a C compiler.

Rust works fine without an OS. Some of the nice-to-have-stuff (inline assembly) aren't stable yet (I have been meaning to push for this with an rfc), but they'll get there.

Rust also has templates (or features that work like C++'s templates) and they are just as complicated/powerful. For example, here is a Rust function for inserting or updating a key in a map:

    fn insert_dup<K, V>(map: &mut BTreeMap<K, Vec<V>>, k: K, v: V)
        where K: std::cmp::Ord,
    {
        map.entry(k).or_insert_with(Vec::new).push(v);
    }

The same function in C++:

    template <typename K, typename V>
    void insert_dup(std::map<K, std::vector<V> > &map, K k, V v) {
        map[k].push_back(v);
    }

The C++ code is shorter because if the "magic" operator[], otherwise they are roughly the same. Imo, templates are very useful because otherwise you can't make efficient statically typed containers.

I would say that Rust generics are less complicated (and less powerful) than C++ templates. C++ has stuff like SFINAE which gets regularly used to do all kinds of black magic. C++ templates also are monomorphization-time typechecked -- this makes them a more powerful form of macro, and this does mean that C++ templates let you do a lot more than Rust generics.

Rust generics are early-typechecked. You can't call a method on a generic parameter unless you have bounds saying that you can. And, similarly, you can't substitute type parameters in places where the bounds don't agree. This means that there are much clearer API boundaries (no more documentation snippets saying "T must have a method .foo()" or "specialization FooTrait<T> must exist") and cleaner error messages, but less metaprogramming power. Rust is hoping to make up for that loss of metaprogramming power elsewhere, but in a vacuum C++ templates are more powerful (though they have other downsides)

(FWIW you can index BTreeMap or hashmap as well with []; the difference is that [] will panic if it can't find the item. entry() gives a reference to the entry which you can check for emptyness and update before pushing if necessary. In C++ most things get implicitly initialized so that's not a problem)

I stand corrected. Though I've rarely seen templates used for anything other than for implementing generic types. Certainly not in the C++ code bases I've worked on. For example, I know templates specializing on values are possible but I haven't seen any non-toy examples making use of that.

You've been luckier than I, then :)

I've not seen much use of SFINAE, just enough SFINAE is a "core" type that makes it infect everything.

You only gave an example of generics, which a lot of languages have including Java, C#, etc.

C++ templates are unique in that they let you do a lot more than that; for example, you can have a different implementation for one specific type. std::vector<bool> is implemented differently from any other std::vector<K>. You can also have templates over values, not just types; so you could define some T such that T<5> differs from T<6> in some way.

I don't know rust; does it allow stuff like this?

We do not yet have type-level integers; they are highly desired by a subset of Rust programmers, and there is an open RFC.

And for programmers who are desperate to use type-level integers, there exists typenum, which is an encoding of integers in Rust's type system. They can also be used to parameterize array length (the generic-array crate), one of the main uses of such a beast.

That said, I am also looking forward to true type-level integers; they're needed for the truly proper translation of fixed size arrays in the Fuchsia IDL (fidl).

Rust has specialization (newish feature). Value generics aren't there, but lots of folks want them, so we'll see.

The issue with abstracted languages is it's hard to make a quick mental model of what could be generated by looking at the code itself as you have to understand n levels of abstractions to understand time/space requirements (C somewhat suffers from this at the compiler level). Both abstracted and terse languages have upsides and downsides, one of which is expressiveness which in turn theoretically allows for more optimizations given a sufficiently smart compiler.

I think an optimal language would allow writing optimizations from within the language itself which would make it abstracted _but_ to also allow functions to be types themselves if you will and hold required compiler enforced time/space requirements.

>> Rust is much harder to learn than C

Hmm. I've been seeing a LOT of posts and even presentations from folks claiming they've struggled with C/C++ and "systems" programming in general but have been able to take up Rust successfully. I'm with you on this; I've had long experience in C and have been dabbling in Rust for a few years and I think C is easier to understand, but unless I am to dismiss what many people have claimed as their own experience I realize that this is probably my internal bias.

The one thing that recurs among people that have trouble with C et al. are pointers. That doesn't surprise me; I did some tutoring in C in the late 90's and pointers are definitely a trouble spot for many new C programmers. To me it's all second nature and I see the *'s and &'s as simple operators doing simple, easily understood things, but I learned first hand that this is often _not_ easy for learners. While rust does have pointers they're are usually `hidden' and tend not to intrude in most Rust code, and I believe this is one reason some people and get on with Rust where they struggle with C.

The C compiler is often the first thing ported over to new architectures because it is fairly easy to do. Rust probably will not come close to being that universal.

On the desktop side of things, it will probably continue to be the favored systems language until universities start incorporating rust into their curriculum. Very few people have the motivation and incentive to learn a new language to accomplish something they can accomplish in a language they already know.

> The C compiler is often the first thing ported over to new architectures because it is fairly easy to do. Rust probably will not come close to being that universal.

Seems to be a good place to ask: Is there a comparison out there of the complexity of a "typical" C compiler versus the Rust compiler? To check if it would be actually possible to port Rust to new platforms easily?

Data point: in 1998, I wrote a C compiler from scratch (preprocessor to assembler) for a new ISA (Cray X-1) to support s/w development in a simulation environment, and it took me about 3 months and 6KLOC to get something that could build IRIX (later Linux) correctly.

Yeah, porting LLVM IR should be much easier these days. Not that it matters though, C legacy is not going anywhere.

I ported C compilers (badly) and manage people who do it (well.) Today you port LLVM, either yourself or using a commercial LLVM backend generator. This makes Rust nearly as accessible as C (in that the platform vendor will bundle clang with some platform-specific extensions but not a Rust frontend with similar extensions. But the heavy lifting is the backend.)

This is not to say that Rust will spread like wildfire, just that porting C isn't easier.

There is also the chance to port backend formats like Mir [0] or Wasm [1] besides LLVM.

[0] https://blog.rust-lang.org/2016/04/19/MIR.html

[1] http://webassembly.org/

There's been at least four or five universities that have taught classes in Rust; I believe there's two active ones this semester, and one or two more next semester. It's a start...

One way for Rust to become more pervasive in the University scene is for it to become an ICPC [0] language of which only Java, C/C++ and Python are currently used [1].

[0] https://en.wikipedia.org/wiki/ACM_International_Collegiate_P...

[1] https://icpc.baylor.edu/worldfinals/programming-environment

Because the amount of code already written in C is astonishing and that's just counting stuff that is in the public sphere.

Once there isn't a dependancy on C-programs or code then C will be obsolete. Now the task comes to rewriting hundreds of thousands of hours of code to make it so that the rust backends for systems are up to spec with what's already layed down.

C is popular because a lot of stuff is written in it and it's the obvious choice due to the tooling for certian tasks.

Because most idiomatic rust operates at a higher level of abstraction than C. Sometimes that matters.

The standard argument is that most of Rust's abstractions are, as much as possible, "zero cost".

However, while Rust's abstractions are very cheap, there is no such thing as a zero-cost abstraction. Why? Because abstractions hide information, and usually provide nicer interfaces than the underlying one. That changes the way you think. If, for example, your stdlib has a standard growable/shrinkable list type that's implemented as an LL under the hood, you'll likely use that structure whenever you need a list, even if you think it's a bad idea to use an LL in that context: it might not even occur to you to check how it's implemented.

Obviously, Rust doesn't do anything this braindead, but it still has abstractions, and those abstractions change the way you think, and may result in suboptimal programs as a result.

This isn't necessarily bad: I don't want to program in raw machine code all the time,and I doubt any of you do, either. But it is something to be aware of.

This is a misapplication of "zero cost abstractions." The slogan, taken from C++, means:

> C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use, you couldn’t hand code any better. - Stroustrup

Everything has costs; that's engineering. But "I chose the wrong data-structure for my task" is not what the slogan is addressing.

Indeed. But my point is that the idea that immidiately presents itself when you think "zero-cost abstraction" is wrong.

>What you do use, you couldn’t hand code any better.

And that will never be true: if you know exactly as much about your usecase as the abstraction, than that might be possible, but that is almost never the case (which was my second point).

> And that will never be true

It is often true. Higher-level Rust code can and often does compile into the same assembly (or sometimes better!) than a lower-level construct. That's the entire premise of optimizing compilers. They're not perfect, but they do achieve this goal more often than "never".

See the Option comments above for one trivial example.

There is no such thing as a zero-cost abstraction.

While it would probably be incorrect to claim zero cost across the board, there are abstractions that can be optimized to zero cost. For example, in Rust you don't use pointers that can be NULL, but the Option type which can be None. In the usual case, the optimizer translates this to the same assembly as using a raw pointer with NULL instead of None. So in the usual case, there is such a thing as zero-cost abstraction.

But the way that you use Option might differ from the way you use NULL, resulting in costs in the implementation that may not exist otherwise. This is unlikely for that exact case, but very common with other abstractions.

This is exactly why I was careful enough to include the phrase "in the usual case", because it would not be too hard to doctor a situation where the compiler will not optimize the Option away, either because the compiler is not perfect, or because of some clever juggling, or for some other reason. But in the usual case, you get zero-cost abstraction.

Why would anyone use Rust when C++ is here and is already mature?

I haven't used C++ in a long time, but ... can I still use standard language features (Templates) and my code will compile with one compiler, but not the other? That would be a big reason in my opinion.

GCC and Clang are 100% C++14 compatible, not sure about MSVC but I think it is close to 100% compatibility.

https://msdn.microsoft.com/en-us/library/hh567368.aspx

Why would that be a reason? There is still only one rust compiler.

I'd rather have one C++ compiler that works great on every platform than multiple ones that only work on one (or two) platforms.

GCC is a great C++ compiler that works on more platforms than the rust compiler. Clang, another great C++ compiler, works on at least as many platforms as the rust compiler.

Again, why would this be a reason to prefer rust over c++?

On the off chance that you aren't being deliberately obtuse, here's what's going on:

If, given two situations

1. The the set containing compilers for language L is size 1, and that compiler works on multiple platforms; or

2. The set of compilers is > 1, but there exists at least one compiler in the set which is a) popular for use with language L b) not fully interoperable with the other compilers from the set that satisfy (a); then

situation 1 is the preferable one

Or to put it another way, nobody complains about code not working with compilers that don't exist.

3. The set of compilers is > 1, and there exist at least a popular compiler that works on multiple platform.

Rust is in 1 of course. C++ is both in 2 and 3. In particular for C++, the compiler in 3 works on a strict superset of all the platforms supported by rust.

As you are free to support only this C++ compiler and ignore every other C++ compiler (you must not care about multiple implementations otherwise you wouldn't think that 1 is a good solution), it seems to me that 3 is strictly better than 1.

edit: I do concede that the existence of a popular but non-interoperable compiler[1] does fragment the community and it has been an issue in C++. Things are getting better though, and if rust becomes popular enough it might become an issue there as well.

[1] We all know which compiler I'm talking about.

Rust is off the table when integrating with large preexisting C/C++ code bases for reasons of maintenance and integration with the existing code. For instance, writing a Linux kernel module in rust is possible, but fraught. You don't get access to any of the existing useful macros. You need to write/generate bindings for all of the C code and in order to make it at all rust-like you really need to write wrappers for the C functions. With each new nightly release of Rust or new release of the kernel your module may break.

I've been working on integrating Rust with Firefox's C++ codebase and while it is challenging it's not prohibitively so, tooling like bindgen makes things easier.

Nightly Rust shouldn't be breaking your code. Use stable features, use repr(C) for stuff that's crossing the boundary (we sloppily didn't in some places, this did cause a breakage on a rust up, but that was our fault), and you should be good. Avoid unsafe-code-UB.

Some of us have to choose something now, or at least before Rust becomes mature.

Well because Rust's support for Arduino is still in its infancy [1].

[1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...

Reply on news.ycombinator.com