> There are a lot of things that make Go slower to write than Ruby, but mandatory typing isn't one of them. Rather, Ruby's total lack of typing makes it harder to write: you effectively end up having to write unit tests just to catch typos.
No, you don't. You need unit tests to verify behavior (values) whether or not you have static typing (except for output types with only zero or one values). Now, it's true, that having such tests also verifies, at no extra charge, things that Go’s type system would verify, but without the additional effort of type annotations. But there's no added cost there, it's a net savings.
To abuse Greenspun's 10th - Every untyped codebase contains ad-hoc, informally specified, bug-ridden, slow implementation of types (written as unit tests).
edit: as pointed out - I need type checking on my words
This "unit tests substitute for static types" is a common straw man. Asserts catch similar kinds of bugs to static type checkers with a similar level of effectiveness and cost.
Moreover, they're typically able to do more sophisticated checks than most languages (e.g. similar to the kind of sophistication of Haskell's type system).
(yes, I know what is going to be replied... IME, they actually fail in prod vanishingly rarely)
Tests don't catch all bugs, even well written ones. Infact if tests could catch all bugs, you'd be able to write a test to determine if any program halts (!).
Now let's look at the nature of programmers. What mistakes are they most likely to make on a regular basis? Well they are human, and they are whacking these big fingers at a keyboard. Maybe typos? Also programmers are bad at spelling, from the source code I've read.
Now could a unit test catch all typo-led mistakes? Well I doubt it. Not for a big program with 10's of KLCs.
Does typing help? Yes - and I'd say typing speeds up programming by allowing autocomplete of code (because of less er... typing as in the finger kind). Since the IDE knows the type it can help you find the write method.
> Yes - and I'd say typing speeds up programming by allowing autocomplete of code
Autocompletion is available in numerous IDEs and editor plugins for many popular dynamic languages (and some dynamic language REPLs, too); static typing certainly can provide a source of data for autocompletion, but it's not necessary for it.
Yes, but do you often need to automatically determine if a bug causes a program to run indefinitely or only much longer than expected? That would be the halting problem, yes (strictly speaking, some subset of it, and for many programs a decidable one).
If you admit that tests are necessary in statically typed languages (which I agree with), then why does having to write tests in dynamic languages make them harder to use? Presumably, you were going to write them in the statically typed language anyway.
Yes and no. It’s true that cleverly written tests encompass bad input, but this also means you need to add an additional layer to your test thinking, which depending on who is writing those tests might might yield results of varying quality... Or you could try fuzzing?
> It’s true that cleverly written tests encompass bad input, but this also means you need to add an additional layer to your test thinking
Sure, you have to deal with more cases in running code if they aren't foreclosed by static guarantees, but you are either adding the thinking to code static guarantees and you are doing the thinking to code tests, and I've seen overpermissive types from too-shallow thought on that (even when it's not due to insufficient expressiveness in the type system) plenty of times to not think its substantially less of a risk than inadequate testing.
I'm not against static typing; I definitely think it has an important place in the toolbox, butnmy experience doesn't align with the idea that static typing is universally better for rapid prototyping.
No, you don't. You need unit tests to verify behavior (values) whether or not you have static typing (except for output types with only zero or one values). Now, it's true, that having such tests also verifies, at no extra charge, things that Go’s type system would verify, but without the additional effort of type annotations. But there's no added cost there, it's a net savings.