3 ms·

>However, it was only 1900 lines of Go (about 50% more than the 1300 lines of Python). >However, I’d seriously consider using Go for larger projects (static ty

>However, it was only 1900 lines of Go (about 50% more than the 1300 lines of Python). >However, I’d seriously consider using Go for larger projects (static typing makes refactoring easier) Assuming a fully tested codebase and a relatively sane runtime type system, I'd much, much rather maintain the shorter codebase than the statically typed one. Having less code makes refactoring easier.

boomlinde 9y ago
Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. You move the type specification out of tests and manual documentation directly into the code where you'll find out at compile time what you did wrong. Not at run-time, or during testing because you diligently wrote a test that considered the case. I agree that brevity sometimes aids refactoring, but there are many parameters that have to be weighed in, and often I find that the benefit of static typing outweigh whatever ignoring the type or checking it at run-time might offer.
- crdoconnor 9y ago
  >Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. I've not found this to be true, and tests that do type checking are a waste of time in any language. Bugs that are caught by static type systems are almost always caught by a combination of behavior tests and a sprinkling of sanity/type checks on border code (e.g. a module's publicly facing API). >you'll find out at compile time what you did wrong In a fully tested code base that is regularly tested the distinction between compile time and runtime does not matter a lot. By contrast n code bases in dire need of tests (which is more common than generally assumed), the distinction is absolutely vital.

boomlinde 9y ago

Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. You move the type specification out of tests and manual documentation directly into the code where you'll find out at compile time what you did wrong. Not at run-time, or during testing because you diligently wrote a test that considered the case. I agree that brevity sometimes aids refactoring, but there are many parameters that have to be weighed in, and often I find that the benefit of static typing outweigh whatever ignoring the type or checking it at run-time might offer.

crdoconnor 9y ago
>Assuming a fully tested codebase, there is an overhead in writing and maintaining unit tests that has to be considered as well, and using a static type system obviates a whole category of them. I've not found this to be true, and tests that do type checking are a waste of time in any language. Bugs that are caught by static type systems are almost always caught by a combination of behavior tests and a sprinkling of sanity/type checks on border code (e.g. a module's publicly facing API). >you'll find out at compile time what you did wrong In a fully tested code base that is regularly tested the distinction between compile time and runtime does not matter a lot. By contrast n code bases in dire need of tests (which is more common than generally assumed), the distinction is absolutely vital.