Okay, so what I learnt from this:

1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes.

2. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings.

3. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assumptions like whether or not to recurse symlinks (why isn't this a flag in filepath.Walk?). This has resulted in ugliness in your walkFunc callback.

4. You have been able to abstract quite a bit without using Java-like factories, although your inconsistent error passing has me somewhat confused.

5. Since it's so strongly typed and there are no raw pointers, it's not going to be hard to debug at all.

Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. It resembles Algol-68 (yes, a 1968 language) quite strongly, and I don't think it will drive compiler technology. Their syntax is specifically engineered to be parseable quickly (and hence super-fast AOT compilation): what the final program looks like is secondary concern. I'm not sure I see the appeal.

[edit: clarified that the note on compiler technology was an opinion]

> your inconsistent error passing has me somewhat confused.

That was my first somewhat big program in Go plus coming from Python made a bit of hustle here. I still believe exceptions to be much better than this error-returning. :\ Never learned to do it nicely. :\

> Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest.

Yes, this is more or less my feelings nowadays. It's good for certain cases and if I ever need something fast, I'll use Go and not C.

> I'm not sure I see the appeal.

There is some. It's still much simpler than C (GC + stricter compiler), plus it has goroutines (not much in this app, though), plus interfaces are really wonderful (you don't need to declare that you implement interface, just implement it and you're done).

On C. C has been around for _much_ longer than Go, and a lot of people understand C inside out. The C ecosystem is fantastic: there are extremely good implementations of virtually everything that you can use to build a production-grade application.

On Go. It'll take time for a programmer to fully understand how to use a new language, and it'll be a long time before great implementations appear. If the language isn't that much of an improvement, why will an existing C programmer take the effort to learn it? Aren't the returns diminishing? Computers will only get faster, llvm will only improve (tooling + compile time + link time): in that respect, doesn't Go seem a bit short-sighted?

In the respect of existing C programmers, maybe. Having myself never mastered C because of its complexity, in a few months part-time effort starting from getting a book on Go I built a sophisticated website. In the respect of non-C programmers, Go is extremely useful.

C isn't any more difficult to understand, IMO. Obviously Go has the advantage of hindsight and an opportunity to go back on the trade-offs that were made for compiler efficiency before C was standardized. However, at it's core I think C is much more simple than Go and theoretically should be easier to understand.

I find GC to be a useful tool but have you ever looked into the implementation of one? Or have you run into a situation where it was necessary to reason about the performance characteristics of a GC in relation to some algorithm or tight main loop?

I don't find C's lack of GC any more complex than GC. In fact I find it much more simple. It requires more discipline on the part of the programmer (and perhaps that is where the appeal of a GC comes from). Perhaps it's because I started programming with addressing memory and building up a mental model of how it works and have only encountered GC as a useful addition to my programming toolbox (instead of an always-present assumption).

As well, co-routine trampolining (which is what I assume the playful pun go-routines are referring to... please correct me if I am wrong) isn't a very "simple" thing to understand either. At least they are not any more simple than threads so I don't understand how they make learning Go any more easy for non-C programmers (except perhaps exposure to co-routines in a language that already has them like Python).

I guess what I am saying is that you could have just as easily mastered as much C in those few months as you did Go.

I would argue that C is probably the easiest language to understand, if you know the basics of hardware. C is essentially portable assembly. The C standard is tiny, and the behaviors are very clearly defined. The challenge is not in understanding the language, but rather in honing the engineering discipline required to use it to write real-world programs.

It lacks a garbage collector because there was no concept of garbage collector when the language was created. A C program does not provide enough information for a good garbage collector: the best we can do is a conservative garbage collector, Boehm. The garbage collector adds to the running-cost to the program for the promise of automatic memory management. While the GC might run concurrently, any sort of relocation (for compacting) will require it to pause the entire program: these GC pauses can be fatal if your program is the Linux kernel or some high-frequency trading application. Even otherwise, it is important to remember that every GC introduces trade-offs; the "freedom" from manual memory management is only worth it if your GC is good.

When I'm not writing C, I like writing Ruby. I like that it's a beautiful evolving language packed with features. And for the little applications I'm writing, I don't care even if it takes a second longer. I like that I'm not being verbose about anything, and not manually managing memory. Writing something like Jekyll in C would be an absolute pain in the arse, and totally not worth it. Obviously, the lesson is: use the right tool for the right job.

The pthreads API can certainly be very intimidating, and it requires a lot of practice to master threading in C. I like that Go has taken the concept of coroutines from Lisp (Scheme's call/cc) and turned it into something called Gorountines in imperative land. Although it's nothing novel, I won't deny that it's a nice abstraction to work with while doing multi-threaded programming.

If we were to redo C from scratch today, I'd definitely bake in more safety features. Probably design a close garbage collected dialect. For better or worse, that's an entirely theoretical scenario: we have Go today, but I'm not sure where exactly it fits in:

1. It obviously can't replace C in linux, git, zlib, ssh, openssl, libcurl, nginx, varnish, or anything as core.

2. Since it doesn't have generics or any higher OO features, it can't displace C++ in chrome or llvm.

3. When python, ruby, javascript are around, why will anyone want to use a strongly typed language for writing web applications? Okay, maybe some intensive web services like search.

Tools? The most popular Go repositories on GitHub are dotcloud/docker (software deployment tool), burke/zeus (Rails preloader) and ha/doozerd (a very specific kind of datastore).

Might be useful in Android development, but is everyone's stuck in a Dalvik swamp there.

Well, here you go: https://github.com/piranha/gostatic

Wasn't pain in the ass, wasn't hard, works so much faster than Jekyll (or my previous engine, cyrax, which was in Python), that it's even funny.