When I was first hired out of college, I started working with some software in the mil-sim sphere that is over 20 years old. Often times I was given a task and told to look at similar code in the program and emulate how it was coded in other parts, and build what they wanted the way it was already done. I would pour over dozens of classes and compare how each of them worked to come up with similar structures, and I saw everything from reflection, to factory of factories, to singletons.
When I finally decided on a solution, I would take it to one of my seniors and propose it to them. I remember the first time I suggested a singleton though. It was a reaction of dismay. Despite every single example I could find for what I wanted to do being in this pattern, my senior didn't like it. I didn't know why. We discussed it with him asking me why I wanted to use the pattern, and what I wanted to do. Eventually he realized that what I really needed was a single class only ever being instantiated once, and this pattern actually fit the bill. He signed off on it. He never explained why he found the concept so abhorrent.
I had many patterns in that code base that I learned over time to be wary of. Either I had to think and make sure that it was exactly what I needed, and had to learn why I would need to use that pattern, or I learned that the patterns in the code were being used wrongly and I needed a new pattern.
I don't think singletons are an antipattern. They can be difficult to work with and test, but if you need exactly what it provides, then you need a singleton. Nothing else will suffice. How you implement it, that's up to you. Though I've only learned the 20 year old one right now, I'm not above learning something new if it's better. Just remember, make sure when you make a singleton that you will never, ever, need more than one of the class. If you think you might need several, an object pool might be better, or just find a different pattern.
