I feel like there's much ground to explore in the realm of stronger guarantees. In plain old C, there is absolutely no way to guarantee that a function will not do anything obnoxious and just return a result. That is largely true for most "mainstream" languages, which are all more or less inspired by C and its predecessors (ALGOL). In fact, in Javascript it goes so far that you can't trust the object prototypes because any of them can be changed.
True, common sense and coding conventions dictate that you simply shouldn't write things prone to be impossible to debug and break random pieces of code in an unrelated part of the project. That is not the problem, though - getting bugs because you've forgotten a side effect somewhere is quite a common occurrence. And besides - how much do you trust external libraries not to do the same (obviously not an issue when it has a large open source community, but that is not always the case)?
Now, on the other end of the spectrum we have things like the monads in Haskell, which are basically computations/side effects in a box. We have contract programming to guarantee the structure of the data. Pure functions that you simply know that you can call in whatever order and however many times you want and the result will always be the same, with nothing breaking behind the curtains.
It would be interesting to take these ideas of managing effects and having a stronger type system back to a C-style language and seeing how they work out. At the very least I'd certainly be happy to never dereference another null pointer ever again, for instance, or calling a writing function and knowing that it can't delete my data (placing your own guarantees is kind of moot when a function can access all of the standard library in the background). In a sense, it's like how you don't have to worry about a function leaking memory or memmoving into your own stuff in a garbage collected language that doesn't expose memory management.