redbad

I don't mean this glibly, but just in case you aren't playing devil's advocate: you sound like an asshole, and I would not hire someone who made a comment like this one. ($0.02 and all.)

I guess there's a good reason for that...

    view := Views{
        DIV("myclass",
            H1("Example HTML structure"),

Yowsa. No thank you.

This is a really strange opinion. SQL is an awesome DSL for interacting with structured, relational data. Got no idea where you get your 90% stat from; seems to me that's a product of your personal ecosystem rather than an objective statement about the universe.

The first two stories are notable in how they reflect the terrible practices of the teller.

"Our distributed application produces the same type of error after the same period of time in totally different data centers. We have no idea why, but moving data centers seems to help, so we just keep doing it. #YOLO"

"We've built a product on a data store and library we don't understand even the highest-level constraints of. That ignorance bit us in the ass at peak load. We patched over the problem and continue gleefully into the future. #YOLO"

These stories should be embarrassing, but they're seemingly being celebrated, or at least laughed about. Am I off base?

"Every 20 minutes" for an S-bahn is totally fine! Especially compared to cities like New York, where every 20 minutes for some U-bahn equivalents would be considered good.

I always wonder what basis for comparison people have when they complain about Berlin's public transport. Because, as somebody who's witnessed first-hand how it works in nearly every major metropolitan area in North America, and many across Europe and Australia, I can say without doubt that the situation in Berlin is phenomenal. A few slow or cancelled S-bahns in the dead of winter do not make a system sub-par.

    > somth

What?

    > Nobody wants to write and maintain matchers that 
    > look like: Expect(foo).To(EqualInt64(3))

And nobody does do that. Idiomatic Go is to write

    if foo != 3 {
        t.Errorf("foo: expected 3, got %d", foo)
    }

I truly cannot explain why _so many people_ find this style of testing _so objectionable_ that they invent entire DSLs to avoid it.

I am absolutely not arguing that static/strong typing obviates the need for testing. Unit and integration tests absolutely have a place in statically-typed languages, and it is precisely as you describe: to ensure functional and business-level requirements.

Notice that I said "ensure", and not "describe" or "define". Because I think that's the disconnect. When you come from a dynamically-typed language background, I think you're more apt to believe your testing needs to describe/define your contracts, because you don't have a type system to leverage. But if you _do_ have a type system to leverage, the pathological context that justifies e.g. BDD is no longer valid, and tools like Ginkgo -- enabling "descriptive tests that can act as effective documentation" -- therefore don't make much sense. To me.

Like afandian, I'm a little fuzzy on the particulars of my gut reaction. But it's something along the lines of this: that BDD, or TDD, or test-oriented-development-practice-X didn't emerge from the ecosystems of dynamically-typed languages by accident. Those languages lack an entire class of verification that statically typed languages have by default, and which is actually important. So their practitioners abide tools, idioms, and practices to make up for that deficiency.

Those things aren't all bad, and _some_ of their lessons can be successfully "ported" to languages and ecosystems that don't suffer the same fundamental shortcomings as e.g. Ruby or Python. But when I see developers take e.g. the BDD ethos as axiomatic and just run with it, it makes me feel like they don't really understand what BDD is designed to address. Likewise with hyper-expressive testing DSLs, or the concept of "mocking" as it's normally used.

Forgive the loaded language, but bringing BDD et. al. to languages like Go feels, to me, like cargo-cult development.

I can't help but feel like the authors of this tool (and ones like it) are fundamentally misunderstanding either the language, the purposes of testing, or maybe even static type systems in general.

    So testing double(mocking) in Go is still a big headache 
    in version 1.2?

I'm confused by your meaning. Mocking hasn't ever been a headache in Go. You just tease apart your functional components by using interfaces, and then test at the boundaries with mock implementations.

I don't know about you, but I don't read a screen nearly as closely to my face as I read a book. If, for example, you normally read a screen at ~2x magazine distance, it stands to reason that screen type should be around ~2x bigger than magazine type, no?

The best article I've seen on the subject is this one:

http://ia.net/blog/100e2r/

And maybe follow-up with this one:

http://ia.net/blog/responsive-typography-the-basics

This article is riddled with misspellings, typos, and grammar errors. :(

Medium gets font sizes right. It's one of the few sites that do.

Also, ZooKeeper doesn't implement Paxos.

    > My brain requires braces to line up in the left column, 
    > anything else slows me down. Maybe I'm just old?

One amazing property of humans is our ability to re-shape ourselves in new environments; to literally learn new tricks. The handicap you identify here is only serving to diminish your potential.

    > Although the author touches on some real issues with 
    > writing applications in Go, I do not recommend this 
    > article. The author does not follow the recommended 
    > practice for writing Go applications and the author has 
    > misconceptions about the Go tools.

Strongly agree. The author's workflow is full of antipatterns.

In a package, main or otherwise, files are purely for programmer convenience. They define import scope but are otherwise transparent to the toolchain.

    > The Go libraries are something very new. People who    
    > developed the libraries know them inside out. Outside of 
    > that group of people, there's certainly much less 
    > knowledge about them.

I guess it's a tautology that the people who developed something know it best, but you're being really disingenuous here by implying that only those people would be capable of doing a project like this. Go's stdlib HTTP server takes great pains to be accessible and powerful.

Nice overview. Somewhat frustrating to see non-gofmt'd code examples. Fix that up :)

_delirium is saying Debian on {kFreeBSD,HURD} are near-experimental, not that Debian itself is.

Shared cultural values in the US definitely do not include well-fitted clothes, outside of niche markets like fashion or design, in major cities like New York.

Please don't meta-moderate my contributions to this community.

    > I wear crocs to work. 

And I guarantee you people take you less seriously as a result of it. You can say "their loss!" and scoff at the absurdity of it, but that's a coping, rather than fixing, mechanism.

I don't know if you've observed normal people lately, but wearing well-fitted clothes is pretty clearly not "the mainstream".

An ORM is absolutely not a requirement of a functional web framework. Many people, myself included, consider ORMs harmful.

Cool. Seems like their head is in the right place: designing for productivity and usability. Kudos.

Thanks for your pedantry. It really adds some signal to the noise.

You appear to be using the logo form of Sparkasse, a relatively large German bank.

http://www.sparkasse.de

    > Maybe the sentence was too harsh, but I have little 
    > sympathy for them.

I cannot rightly comprehend the sociopathy that assembles the facts of this case and renders a judgment like the above. I hope you never need stand before a jury of your peers.