from a testing point of view this looks pretty week. I would not bet my business on something that has not a testing culture.

What? Go check out any moderately popular library in Go (including packages in the standard library), and I bet you're fairly likely to see a `*_test.go` file somewhere (perhaps more than one).

Unit testing in Go is refreshingly simple. And it comes standard with the Go toolchain.

I wouldn't say Go doesn't have a testing culture. On what basis do you make that assertion?

I write better tests for my Go code than for any code in other languages that I write. But maybe I just think in complementary ways to Go's testing philosophy.

The talk that I gave just before the one linked above talks about testing: http://vimeo.com/53221558

What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice.

I haven't came across any Go libraries without tests.

* as far as I can see very few go projects use CI (e.g. travis)

* gospec seems to be dead/not widely used

* I don't see projects measuring their code coverage

* As pointed out in my first comment, I couldn't find high level testing tools and none of the repliers could name one, too.

If you don't have tests to measure function and performance, any new technology is just playing another round of Roulette and/or "bike-shedding". Most projects and companies — to my knowledge — don't fail because of 30 servers for Rails but in the inability to iterate (to find a profitable business segment) without investing/burning bulkloads of money re-engineering. Therefore any serious business use requires a deep evaluation and comparision with existing methods, especially in the quality of service sector.

The Agile/XP/TDD/BDD-movement was not created because of "bad and slow" programming languages. It's because failure happens all the time if you like or not. It's about dealing with the omnipresent risc and changing specs.

Agreed, but something you also have to worry about is your stack becoming unmaintainable. Sometimes it's worth re-engineering your stack. For instance, even the simplest programs have a "time until too complex to safely be maintained".

I suppose you have to make that time far enough away that it won't affect your business. If you go past it, your good developers will leave and you'll likely only get lower class devleopers who have to take the job.

As a result your entire stack will suffer. The business side is important, but the entire engineering side can die if you neglect it too much.

Complexity must be managed.

That said, you are correct about:

* Few projects use CI. I think this is due to the fact that most of the libraries being developed are done by very small teams that see it as too much overhead.

* Same with code coverage.

* Most find the testing that Go uses for the language itself to be more than enough.

I think that Go has a much different attitude towards development than you are used to.

I can't quite quantify why and I could be wrong, but I suspect not all of the testing methodologies you talk about are necessary.

Would be great for someone else also experienced with Go and experience with the type of testing environments rmoriz describes to chime in!

Hmm I see a lot of opportunity