Yes static YAML for config. It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret.

Yes static YAML for config. It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret. Yes external libraries. 80% of those are for testing (as is the Python stuff). In Go land you should effectively ignore the vendor folder, I check it in for developer convenience and system stability. Compare to Rails which has a massive dependency graph. And one that has to follow your app around for every build and deploy. I will absolutely grant that for SQL CRUD apps, you still can't beat the Rails tooling. Migrations, rake tasks, ActiveRecord, Scaffolding and the Ruby REPL to poke at your models and data are very useful. But decoupled tooling is getting really good. The https://github.com/marmelab/admin-on-rest https://github.com/marmelab/admin-on-rest project is better than Django Admin. The basic CRUD stuff is just as easy, then it's infinitely more configurable with a bit of custom React programming. And it's not coupled to any language, framework or database. Finally cost is effectively zero for all of these options to start. AWS and Heroku offer a generous free tier. Developer time is the real cost to watch. But in terms of raw resource consumption, static Go binaries talking to DynamoDB plus a static React page are obviously less "expensive" than Ruby VMs talking to a dedicated Postgres server and rendering HTML pages.