4 ms·

* 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

by rmoriz 14y ago

* 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.

codygman 14y ago
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!
gregors 14y ago
Hmm I see a lot of opportunity

by rmoriz 14y ago

codygman 14y ago

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!

gregors 14y ago

Hmm I see a lot of opportunity