Whenever I take a crack at making a new application with rails, the sight of seeing rails create all those new files is a strange mix of satisfaction and being overwhelmed.
There's the app folder, the bin, the config, the db and then a few others on top of that. More or less, it'll look like the below.

I figure this calls for a quick overview of just a few of the different folders that rails provides for us to help us get our bearings and not have that "oh gosh, what have I done?" feeling.

/app

The app folder contains assets, controllers, helpers, mailers, models, and views (& views/layouts!).

Essentially, this is the bread and butter of the rails application. The app folder organizes the application's MVC components. That is, it has a folder that contains the apps models, views, and controllers, all separated from each other to follow standard MVC convention.

./assets

This folder contains images as well as javascript and CSS files that help style your application. These are all generated by rails

./controllers

"Controllers" contain, well, the controller files that handle user requests and that tie our rails MVC model neatly together.

./helpers

This folder is full of .rb files that contain modules. Essentially, files here are used to keep our model and controller code DRY.

./mailers

Mailers seem to be one of the more mysterious -ahem, advanced – concepts in rails, but essentially, any logic for building out a mailing functionality in your application goes in this subfolder.

./models

Our classic ol' models subfolder holds our class models that deal with the database and the data stored in it.

./views

"Views" contains our layouts folder, as well as any corresponding controller "views" folder (which would be the pluralized version of its respective controller). The layouts can be thought of as the standard "look" of the webpage, while the "views" are the particular flavors and logic of each controller. These two files work together to display our application on a server.
Files here are written in embedded ruby (.erb) that create HTML code.

/bin

Contains our scripts that start, setup, test, and run our rails application.

/db

The database folder! Here is where your database schema lives, as well as your database migrations and your seeds.rb file. Our database can only be changed through our migration files (and by running the rails db:migrate command) and our database can be populated using the seeds.rb file.

/Gemfile & /Gemfile.lock

The Gemfile and Gemfile.lock files can be thought of as sister files. Whenever you find a cool new gem that adds some awesome functionality to your app (and lets you escape the task of reinventing the proverbial wheel), it gets installed in your app when you place that gem in the Gemfile file and run the bundle command. This will then auto-generate (or update) the Gemfile.lock file, which should itself never be directly touched. It lists out all the already-bundled gems and their current working versions in your app.

/lib

This is a bit of a tough one. Rails documentation describes it as:

Basically, any kind of custom code that doesn’t belong under controllers, models, or helpers. This directory is in the load path."

Which helps no one. There is actually not a very wide consensus about what exactly should go in here, and many sources seem to work out their own conventions regarding this folder, or ignore it altogether.

/log

The log folder is your overhead glimpse into your rails session. SQL queries, error messages, request information (including URL, controller, params, and view information) is all stored in this folder. It tells us the history of our time on our application that we can peruse and use to track down bugs and errors.

/public

The public folder is used to hold static files. Error files (as in, what to display in case of an error happening)for example, could be stored here. However, storing files in the /public folder is not highly necessary.

/test

Contains the tests for your application that helps guide you to full functionality. These are auto-generated, but custom ones can certainly be built out.

This overview is in __no way__ exhaustive. Really, it barely scratches the surface. But hopefully now firing up that rails new command is now just a little less mysterious.