redbad

    > in Java, I frequently ask my tools, "Give me a list of 
    > classes that implement this interface,"

You don't generally ask this question when working in Go, because you don't really construct your "type" system in these terms.

I guess what you call an "internal DSL" I call an API.

    > Whenever you're creating a function, you're defining a 
    > verb in your domain-specific implementation. 

Yes. And by virtue of it being a function, i.e. a first-class operator in the language I'm working in, I also know _prima facie_ the semantics, cost, and implication of that verb.

This is critical and necessary knowledge. And it's precisely the knowledge that I _don't_ get (immediately) when I use a DSL. I have to know both the semantics of the verb within the context of the DSL, and the semantics of the DSL (as a whole!) in the context of my programming language.

That additional step is, more often than not, a significant burden. I'm disinclined to bear it, no matter how facially elegant it may make the solution.

    > The real discussion should be - in what contexts do you 
    > really need re-usability and/or composability and/or 
    > succinctness? Not always, I'll grant you that.

This is a disingenuous framing of the problem.

    > DSLs are used in production code, and solve real world 
    > problems better than ad-hoc repetative code does.

And this is called the "argument by assertion" fallacy.

I'm sure there are a lot of problems where DSLs make sense to use. They're simply not _most_ problems.

    > Essentially, you're saying that the point is not to use 
    > DSL's. The benefits of DSL's are explained everywhere, 
    > so I don't think I need to repeat them here...

DSLs aren't a gimme. In production code, produced and maintained by a team, and iterated through a lifetime of morphing business requirements, DSLs are almost always more of a hindrance than a help, because they impose an additional cognitive burden on their manipulators.

They're lovely to write, and elegant in a closed system, but in The Real World(tm) where we all live and work, we don't generally have the luxury of writing software to solve those classes of problems.

    > Structural typing is nothing like duck typing. People 
    > saying that don't know what they are talking about.

Structural typing is at least facially similar to duck typing. People contesting that are being pedants.

    > I only interact with colleagues and I can't imagine them 
    > caring what I wear.

We do. We don't tell you, and if we're any good we don't show it, but we notice and we draw conclusions about you.

    > with a near 50% youth unemployment rate in some 
    > countries.

Can you name one besides Spain?

    But this is 2013, there are somethings that expected to 
    come from a language default. 

Very true!

    Exceptions are one of them,

Very false! :) Exceptions have a lot of detractors.

    > Development has several modes. One mode is "hacking",
    > just hashing out what you want until it works and is 
    > elegant enough as a solution, perhaps changing your mind 
    > frequently when you see how it works in practice. 
    > Another is "polishing", carefully annotating, cleaning 
    > up, documenting, burning off loose threads, making sure 
    > the test coverage is top notch, etc.
    > 
    > The problem is that Go's compile-time strictness lends 
    > itself to the "polishing" phase, but not to the 
    > "hacking" phase.

When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment.

That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.

    > the supervising goroutine now looks a bit odd:

This is totally valid:

    select {
    case <-doneChannel:
        //

    > What is not cool about Perl?

Almost everything is not cool about Perl. Perl felt crufty and ancient even when I was learning it fifteen years ago. It's only gotten weirder, cruftier, and more ancient since then.

Embedding is not strictly the same thing as inheritance.

    > Why the irony? How many cluster deployments you know 
    > where you "spin up instances all the time"???

Any cluster environment whose applications abide 12-Factor semantics stands to benefit greatly from low startup times. This describes both SOA environments like Amazon and Netflix, and PaaS environments like Heroku and [what is enabled by] Docker.

http://12factor.net

    What question to ask so the obvious answer would 
    be "Use Go?"

Writing services in a SOA tech stack.

It seems silly, but it's simple, powerful, and removes a large class of ambiguity from your programs.

git absolutely is a deploy tool.

The Apple wireless keyboard is the best keyboard on the market right now IMO.

ORMs are broadly considered antipatterns in Go.

Lack of comments is at once annoying and beneficial: it forces your [JSON-based] configuration to be simple.

    Specs have had business concerns in them since... ever.

Good specs haven't.

Badges ruin communities, full stop. Please keep them far away from this software.

Are you aware of gofmt's rewrite rules?

http://golang.org/cmd/gofmt/#hdr-Examples

Pretty powerful stuff.

The arguments to common UNIX commandline tools like sed or xargs are without doubt going to be longer-lived than the arguments to your helper script, likely even longer than the language your helper script was written in, and maybe even longer than the idioms and philosophies you had in mind when you were building your tool(s).

Calling the basic operation of these cornerstones "useless" speaks more about your disposition than the tools, I think.

    > Solr uses ZooKeeper under the hood which implements the
    > Paxos algorithm

ZooKeeper does not implement Paxos.

This article is full of grammatical and spelling errors, and reads as blogspam.

    Go implements OOP slightly differently than other
    languages. Functions are defined on an interface, 
    not a class or subclass.

This is not quite correct. Functions are defined on concrete types. Interfaces are named collections of functions, used to describe behavior.

This is indeed what Go is great for. But your code example is a bit wonky :) Specifically,

    for {
        select {
        case r := <-ch:
            // do something with r
        default:
            fmt.Printf(".")
            time.Sleep(5e7)
        }
    }

You're needlessly blocking 50ms on every iteration. (Side note: time.Sleep(50 * time.Millisecond) better captures your intent.) Better to reformulate that as

    for {
        select {
        case r := <-ch:
            // do something with r
        case <-time.After(50*time.Millisecond):
            fmt.Printf(".")
        }
    }

Or, if you don't need the dots in the output,

    for i := 0; i < cap(ch); i++ {
        r := <-ch
        // do something with r
    }

    > Comparing two things is different from equating them.

True, obviously.

    > It's not offensive to compare Stalin to anything,

False.

    > including those things you hold sacred. It doesn't
    > imply they are equal in all respects, and any inference 
    > to that effect on your part is in error.

When you compare X to Hitler, or Stalin, or Pol Pot, or the devil, you're necessarily invoking an element of offense to make your broader point. Rightly or wrongly, those figures are inexorably bound to offend. It's not possible to simply assert that away.

Am I the only one who thinks Jeff Atwood is completely without the necessary credibility to spearhead an effort like this?

To say nothing of the time-tested idiocy of designing a spec by committee? IEEE telco protocols being the canonical example?

The whole effort seems like a terrible idea. Gruber's responses seem to me to be completely appropriate.