One really interesting thing you may not have spotted in the release notes of #golang 1.21 is the following line:
"Package initialization order is now specified more precisely"
This is quite a big change, as it impacts how the init() function works. Previously it could be difficult to know what order the init function in different packages would be run (https://t.co/jtSGbJmqEr) but this changes that. The new Algorithm is:
- Sort all packages by import path.
- Repeat until the list of packages is empty:Find the first package in the list for which all imports are already initialized.
- Initialize that package and remove it from the list.
This is a positive change, but it does mean that this is a breaking one; you should test your applications thoroughly if you are upgrading to 1.21.
Does this mean we can/should use init more?
I don't think so, no.
Init was always been seen as anti-pattern by many and some style guides such as Thanos(https://t.co/AHF7Drf6il) go as far a to say "no init". This is because they can cause global changes that have side-effects which can be difficult to track down .
The only init function I use regularly is to setup:
https://t.co/LI3ilSyrg5 (under the hood it calls init)
How do you use init functions? Does this change change the way you think about them?
🎙️ Our newest podcast episode is live! https://t.co/3eni8bJ6pX
Host @classic_addetz is joined by @thedevel, Director at @synadia and #nats expert. He joins us to discuss #eventdriven and #resilient microservice architectures. Then, he gives us a peek into new NATS features.