I'm documenting my learning of Drupal 8 in the hope that it helps keep it in my brain, and may possibly be of use to others dipping their toes into the very different world of this upcoming release.

Learnt so far:

1. Drupal 8 is more framework-like than Drupal 7 (being based on Symphony), and it brings in concepts of services and a dependency injection container. I've worked with Slim (whose website is getting slowly less slim!) and Laravel and I like that this aproach gives more opportunity for testing. There's a really interesting article on someone who went Drupal 7 → Laravel → Drupal 8.
2. Entities rule the day. Whereas in D7 they were a nice idea but only partially implemented, in D8 they've taken over and are now used for all content and configuration. Also, config can be more easily version controlled, but I've not quite figured that out yet.
3. It's not MVC, it's PAC, so the templates (Presentation) have no direct access to the data (Abstraction); instead they must be fed only by the Controller. We had this model in Drupal 7, too, but as templates were PHP it got a little more confusing. Read a helpful summary of MVC vs PAC.
4. It's jumped from being largely function-based to being heavily object oriented, with PSR-4 namespacing. So a file system that deals with tens of thousands of tiny files and a PHP that caches code should help performance a lot, I'm guessing. Drupal 7 has ~3.5k files, Drupal 8 has ~12.5k files.
5. Configuration files in YAML format.
6. You need the latest version of Drush to work with D8. See blog by Amber Matz.
7. Custom modules, themes now in /modules, /themes (where core was in D7).

Hello World

There are lots of examples on the web doing just this so I won't repeat them here. But I was relieved to find that it worked when I did it, too!

I like that routes' paths include named placeholders and that there's the possibility for the values held by these to be magically replaced (by route filters) with full fledged objects. e.g. a path like node/{node} means that the controller is called with $node being a fully loaded Node object. Your Controller's method must include a parameter with the same name, i.e. $node. This is much nicer than trying to count N parameters and get them in the right order.

I like that a route's path components can be validated against a regular expression - this seems a sensible move to me, shifting more code out of controllers/page callbacks. If the regex doesn't match, neither does the route (so 404).

I'm not quite convinced by the underscore in route keys. Apparently everything without an underscore is an argument to the route, but I don't fully understand this and the distinction does not add clarity to me at the mo. Perhaps it will when I get further in.

Theming

Themes are declared with much the same hook_theme() functions as before.

Twig templates are assumed, and it's assumed that these have the same name as the theme name except with _ changed to -. Eg. in hook_theme return [ 'my_theme' => [ 'variables' => ['foo'=>NULL] ] ]; would set up a theme to expect a template called my-theme.html.twig

But caching complexity/flexibility has been really expanded, with cache keys (identify the thing being cached), cache contexts (e.g. timezone), and dependencies (e.g. if it depends on a user and that user is updated) as well as max-age.

Next: create a new content entity

Next I want to learn about making a content entity or two, which is something I never did in Drupal 7 because of the huge amount of boilerplate required, but I think a new console tool for Drupal 8 is going to help me...