You don't get portability from chef and others. You get a framework where you can implement your deployment with a case for each system you want to target. Past some toy examples, it's on you to make it "portable".

This is 100% correct. If you go look at the Chef cookbooks for any popular piece of software, say Apache or MySQL, the code is littered with conditional logic and attributes for different Linux distributions (not even considering entirely different operating systems). Every distro has different packages as dependencies, install locations, configuration file locations, service management, etc.

Docker (all container solutions really) aren't a panacea, but they solve a very real problem.

By portability I was referring to being able to move your application to different servers by running your provisioning system.

What do you mean by dynamic nature? Because how I've been using it it's very much static to what I have defined in my inventory.

I was referring to the language you write playbooks in (YAML). There are no static checks, other than a dry-run that only tests for syntax errors. Frankly, I haven't heard of any provisioning system written in a compiled language. I wonder why.

NixOS kind of fits the bill (it can generate complete OS images from a recipe which is IIRC statically typed and "compiled")

If it looks waaaay different to puppet, ansible and chef, there's a reason for that :) Doing provisioning "properly" means managing every file on the drive...

I know about nix, but I'm referring to the language you use to describe the final image. Actually, this part is not a problem. The problem comes in the deployment part.

For example, there's no concept of `Maybe this request failed, you should handle it`. So when you run the deployment script, the request fails and the rest of your deployment process.

Defining the possibility of failure with a type system would force you to handle it in your deployment code and provide a backup solution.