Hacker News new | past | comments | ask | show | jobs | submit login

I don't think Go is attracting many programmers away from C++ (in fact Rob Pike has expressed surprise at this) because it lacks some of the important good qualities of C++: strong typing (which Go lacks because of its lack of templates/generics) and RAII-style resource management. Instead Go is attracting programmers away from interpreted languages like Python since it has many of the nice qualities of interpreted languages while being very fast.

Rust may be a different story (still too soon to tell) because it shares many of the fundamental philosophies of modern C++ without having a "bolted-on" feel. Still, it will be very hard to ever displace C++, because so much code is currently written in C++ and C++ has proven to be a very good language for code that needs to last decades.




> Still, it will be very hard to ever displace C++, because so much code is currently written in C++ and C++ has proven to be a very good language for code that needs to last decades.

I'm pretty sure that Rust devs are aware of that which is why they made Rust compatible with C/C++.


The big issue is that C++ FFIs are notoriously hard to implement. Often C wrappers are the only way to go (Rust has an excellent C FFI). As far as I know, I think D is one of the best out there regarding C++ compatibility, but it is still lacking.


>Go lacks because of its lack of templates/generics

This is one of my big frustrations with Go. I see lots of ugly `interface` based patterns.

I wish more languages would adopt Haskell's typing system (at least partially). It is truly beautiful.


This—also, C++11 is an amazing improvement over C++03, and C++14 looks like another step in the right direction.

For a small example, a friend talked me into implementing a few Scala collection operations in C++11. Here's the result: https://gist.github.com/LnxPrgr3/6547131

Usage looks like this:

    const collection<vector<string>> names = {"Daniel", "Chris", "Joseph"};
    return names.reduce_left<string>([](const string &total, const string &value) {
        return total + ", " + value;
    }) == "Daniel, Chris, Joseph";
    // ...
    const collection<vector<string>> strs = {"1", "2", "3", "4", "5"};
    auto rv = strs.map<collection<vector<int>>>([](const string &x) {
        return atoi(x.c_str());
    });
    return rv.size() == 5 && rv[0] == 1 && rv[1] == 2 && rv[2] == 3 && rv[3] == 4 && rv[4] == 5;
This is from a collection of tests, which looks like this:

    struct test {
        const char *name;
        function<bool ()> fn;
    };
    
    const vector<test> tests = {
        {"Foldleft", []{ /* .... */}},
        {"reduceLeft on empty throws", []{ /* ... */ }},
        // ...
    };
    
    for(auto &test: tests) {
        cout << test.name << ": " << flush << (test.fn() ? "PASS" : "FAIL") << endl;
    }
    
I would've never considered something like this useful in C++03—callers would have to create named functor classes just to do some trivial one-line operation, this vector of tests would've had to have been a series of push_back calls, and iterating over it would've been quite a bit uglier.

This isn't at all an exhaustive list, but these are the biggest things that come to mind when I think of what C++11 gains over C++03.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: