3 ms·
> these dynamic languages doing contortions to deal with basic things like concurrency I get the concurrency gains, esp with older versions of dynamic language
by amirkdv 5y ago
> these dynamic languages doing contortions to deal with basic things like concurrency
I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines.
But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?
- avl999 5y agoYeah the compiler guarantees that a certain class of errors can never happen and thus you don't need to go through significant effort to cover things like error returns. Additionally with a dynamic language where the codebase has less than a 100% test coverage I would find it very hard to refactor anything without sweating bullets. The compiler is giving you a free test suite.
- tptacek 5y agoBecause Ruby and Python force you to unit test for typos. I like and use both of them but if you're trying to argue that the testing problem in Python is the same as that of Go or Rust, that argument will fail.
- amirkdv 5y ago> if you're trying to argue that the testing problem in Python is the same as that of Go or Rust Wasn't trying to make that case, but I can see how my comment could be read that way. I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.
- mixmastamyk 5y agoPyflakes should be the first "test" run, and it finds those kind of issues.