Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

>> 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.

> 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 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.

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 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.

Reply on news.ycombinator.com