>Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster.

Not if you follow the second part of my above advice.

>There are lies, damn lies, and boilerplate code comments.

Since when is a comment that explains what a function does "boilerplate"? I think you are confused.

I've often had to work with code where the comments indicated an entirely different intention than the implementation. As a result, I'm a little paranoid and skeptical, that's all.

I also don't like the idea of having to comment each and every single function. If you have to write a comment to explain what it does, maybe you haven't named it properly?

There are a few people who are cautious and methodical enough to specify all types in comments and keep them correct. But you need an entire team of them, because type comments which are only mostly correct would be worse than useless. And an entire team wouldn't choose a dynamically-typed language that makes those showstopper bugs more likely.

Well, if you're having major problems keeping the project's code and comments in sync, no compiler will save you.

That's exactly how the compiler saves you. A strongly typed routine signature contract is a like comment that cannot get out of sync.