<i>> A straightforward solution of the problem is superior to one that makes you feel like a high priest for having discovered it.</i><p>It is also much better for the team and the company. Beginning musicians are just trying to play. Intermediate musicians are try to play as fancy as they can. Master musicians play what's needed by the tune.<p>It takes somebody who's past all the ego issues to devote their intelligence to making code look simple. It takes great intelligence to solve a complex problem in a way that looks simple and straightforward.
For the love of Thor, please provide a few code examples illustrating the content, hard to get an idea of how to simplify things with Go with mere words and ideas.
So, Go has message passing. Just like Erlang, since 1986.<p>Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake.<p>But it's not enough to scorn the industry; Go's designers also look down their noses at academia.<p>A modern, ML-derived static type system? Generics, which would enable the unwashed mashes to write their own `append`? Ain't nobody got time for that — wait, what? Oh, Rust does?<p>Go's tooling is fantastic, and its pragmatism is commendable, but ignoring the last 30 years of programming language research is not.
I think this is one of the really great things about Go. Some detractors ask "There is so much to be gained by having generics! What would be lost if Go had generics? Nothing! Ergo, Go is wrong to not have generics".<p>This line of argument is flawed. Go curbs the ability of people to write crazy (and ultimately mentally expensive) abstractions. The lack of generics in Go is very a good thing. Especially when it comes to collaborating on a large unfamiliar code base.<p>I have been productive in Go and haven't missed the ability to write generic code so far. Usually it turns out there is another way to achieve what you want without them. If there isn't, maybe I'm trying to solve the wrong problem, or it is the wrong language for the task.
> The channel is the analog to the Unix shell’s | character.<p>This sentence was italicized, and rightfully so. I've written a few small Go programs, but I haven't run into a problem where I thought, "A channel is definitely the right solution here." Yet I love and feel quite comfortable with shuffling data through big shell pipelines. Perhaps I'll think of a channel next time I'm reaching for a pipeline.
I wanted to say this but couldn't find the right words. The author manages to do it. This is something I wrote: <a href="https://github.com/adnaan/hamster" rel="nofollow">https://github.com/adnaan/hamster</a>. The whole experience of programming in Go is like moving from point A to point B in a straight line.
Clever is not smart.<p>Consider this anecdote: I recently put together a DIY 3d printer. I didn't have the right tools to cut steel bar, so I made a clever jig and used a shitty Dremel without enough clearance. Clever? Yes -- it got the job done with limited resources. Smart? No -- dumb, actually. Smart would have been driving 15 minutes to Harbor Freight to buy a $20 cut-off saw.
Perhaps I'm reading this wrong, but if I'm not, it seems to be making a great point but missing a far greater one.<p>This is the more important lesson.<p><i>Replace clever code with unremarkable code.</i><p>Go has nothing to do with it. PERL has nothing to do with it. Switching languages most certainly has nothing to do with it. Keeping yourself in check and stepping back from your problems to understand their fundamentals, then looking for more appropriate and elegant methods of dealing with them in <i>any</i> language is what does this.
It's so strange to me that people describe things like higher order functions and map/filter/reduce as being clever / complicated and think manual iteration and indexing into an array is "simple".<p>I hate to keep linking to this talk because I don't want to look like too much of a clojure fanboy, but I think a lot of people would benefit from re-examining their definition of simple: <a href="http://www.infoq.com/presentations/Simple-Made-Easy" rel="nofollow">http://www.infoq.com/presentations/Simple-Made-Easy</a>
This article didn't make much sense to me. In particular, what was it about the problem that prevents having a "stage" object with a "do_stage" method, which takes the input object and returns the output object (or some error code etc.).<p>I feel like the answer has to do with concurrency but the description in the article was to vague to get a more precise idea.
<a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a><p><i>Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.</i><p><i>And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).</i><p><i>As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.</i><p><i>When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.</i><p><i>By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.</i>