I recently bought one of those stm32F0 discovery boards and am learning to use it. I come from a PIC microcontroller background, where writing to different registers was the name of the game. I see that you can program in a similar way with the STM32 series micros, but it seems like the difficulty of doing similar tasks is much higher.
It really isn't. More features means thicker reference manual, more control registers and control bits, but usually you go with defaults or zero bits, and skip irrelevant documentation, when doing similar things you did on PIC.
For example, configuring and utilizing UART, SPI or ADC, or a similar complexity peripheral is:
On AVR or PIC: around 3-4 lines,
STM32, simple register access: around 5-6 lines (same as in AVR/PIC, but need to turn on the peripheral clock, plus configure IOs to Alternative Function mode, so about 2 lines more)
STM32 standard peripheral library way - still most prevalent on Google hits: around 30-50 lines of copy-paste or autogenerated code. No abstraction provided; you do the same as in "direct register" way, just with a lot more boilerplate code. Just some two years ago this was the preferred "forum" way and you was greeted with a lot of FUD bullshit if you disagreed; now it's officially deprecated, and people are starting to forget it, thank god. So generally, more and more people are using code autogeneration on larger degree.
Go on with your preferred "PIC way", you'll be just fine. It will never be completely out of fashion, unlike most other, typically inferior ways that come and go within the "scene".
The "modern" STM32 trend of autogenerating unmaintainable bullshit mess from a GUI is of course
a lot better than copy-pasting the same unmaintainable bullshit mess from Stack Overflow, so it's getting better, but your chances of actually producing maintainable codebase is better if you keep your PIC C development style.