Rust and Go

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement:

Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem.

He's apparently using each language to write relatively small command-line utilities. If Go is "amazing" at anything, its usually cited as a language of choice for (1) networked systems, and (2) large yet maintainable systems. I'm not sure his initial foray into the language would have provided enough experience to accurately assess those merits one way or the other.

Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: (EDIT: removed pejoratives) if a programmer desired to switch from C/C++ to another language but hasn't by now, why not?

1. They require the performance benefits of C/C++ (and as humanrebar pointed out, manual memory management).

2. They're tied to legacy code, with too little incentive to switch.

3. They have an organizational mandate.

Any programmer who wasn't subject to the above constraints and wanted to switch could have done so before Go showed up on the scene. And if a programmer uses C or C++ solely because the above constraints, Go isn't likely to change that.

Rust may have a better chance of converting C++ programmers, if it offers the performance and control demanded by programmers who are using C++ by necessity. It will be interesting to see if people migrating from Python/Ruby to a higher performance language will choose Go or Rust in the future. Kind of like the OP, I like Go but I'm excited about Rust.

Wow that makes me cringe. This specifically:

> The power of the map/filter abstraction starts becoming more apparent when you do things like

> Filter(someFunc, Map(funcWith3args, vecA, vecB, vecC))

> And you realize you should swap map and filter for your particular app for better performance.

met with this reply:

> vs > [10 lines of code for two for loops doing the same thing] > Using range makes it obvious that there is a performance hit in the first place.

Not a bad write-up. The Rust code snippets can be slimmed down very slightly though. Here's main():

    fn main() {
        let args = os::args();
        let washed_args = args.iter().map(|arg| arg.as_slice()).collect::>();
        match washed_args.as_slice() {
            [_, "review", opts..] => review(opts),
            _ => usage()
        }
    }

although I might actually suggest the alternative approach:

    fn main() {
        let mut args = os::args().into_iter();
        args.next(); // skip program name
        match args.next().map(|s| s.as_slice()) {
            Some("review") => review(args.collect::>()),
            _ => usage()
        }
    }

(this approach requires `review()` to take a `Vec` instead of a `&[&str]`, but that's not a difficult change, and we could fix it using a second line of code if we wanted but at the cost of introducing a new allocation, like the original code does)

For review() I'd suggest changing the original code:

    let cwd = os::getcwd();
    let have_dot_git = have_dot_git(cwd.clone());

    let dot_git_dir: &Path = match have_dot_git.as_ref() {
        Some(path) => path,
        None => { panic!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()) },
    };

to the following:

    let cwd = os::getcwd();
    let dot_git_dir = have_dot_git(&cwd).expect(format!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()).as_slice());

This actually leaves `dot_git_dir` as a `Path` instead of a `&Path`, but I think that's better anyway. It also requires `have_dot_git()` to take a `&Path` instead of (what I assume it takes now,) a `Path`, which is an appropriate change as there's no need for cloning the path.

What an infuriating thread. I guess I'm not the kind of person Go is made for, but the fact that everyone in the thread was so close-minded about what might be helpful about map, filter, and reduce was frankly absurd.

I especially enjoyed the demonstration of map would look in Go code, complete with a useless anonymous function:

> bar = map(foo, func(e T) { return f(e) })

And this guy who doesn't seem to understand the concept of function pointers:

> You seem to equate the function f with a single character, which it's not. The user must write it's implementation, which you have omitted for your own benefit.

tl;dr: Guy who knows Rust better than Go prefers Rust over Go.