Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Singleton Pattern in Go

marcio.io

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Singleton Pattern in Go

#71

Post by incepted »

inglor wrote: post #36
incepted wrote: post #22

Earlier quoted context omitted.

Singletons are useful and wide spread concepts. What is an anti pattern is implementing them in a way that's not thread safe (which is made worse if your singleton is mutable). Letting DI frameworks handle your singletons is the best way to get the best of both worlds.

No no, singletons are pathological liars http://misko.hevery.com/2008/08/17/singletons-are-pathologic... Atomic mutable global state is still mutable global state. DI containers mean you don't need a singleton but can just create a single instance which lets you scope it and does not mix lifetime duration and object properties.

> DI containers mean you don't need a singleton but can just create a single instance

So... a singleton.

Re: Singleton Pattern in Go

#72

Post by fibo »

strictfp wrote: post #24

Coding Pro Tip: Instead of using the Singleton pattern, make one instance of your class at the start of your program and pass it around to its users. Singletons are really just as bad as global variables. Why? Because they are global variables.

I agree,

everybody user a Singleton some time in his life: cause it is often user as first pattern learned and also cause it is a quick and dirty workaround to fix Your code, For onstance to have a single connection handle to a database, instead of review your class diagram (if any).

Re: Singleton Pattern in Go

#73

Post by cryon »

hyperpape wrote: post #55
skrap wrote: post #18

Earlier quoted context omitted.

Totally! I was going to post the same thing. Double-checked locking is either impossible or really hard to get right, depending on the language and architecture's guarantees! If you must use a singleton, I'd really recommend doing the so-called "aggressive" approach, which should have really been named the "actually won't crash sometimes" approach.

In modern Java, it's easy enough if you've been shown the pattern. What's hard is understanding/discovering it from first principles.

You should use enums for singletons i Java. Simple to write, threadsafe and handles serialization. All with guarantees from the Java language specification.

Re: Singleton Pattern in Go

#74

Post by hyperpape »

cryon wrote: post #73
hyperpape wrote: post #55

Earlier quoted context omitted.

In modern Java, it's easy enough if you've been shown the pattern. What's hard is understanding/discovering it from first principles.

You should use enums for singletons i Java. Simple to write, threadsafe and handles serialization. All with guarantees from the Java language specification.

I wasn't actually talking about singletons, just the doublechecked locking pattern. It's also necessary for laziness on objects that are referenced by multiple threads.

I tend to think Singletons are a dubious design pattern, like a lot of other people.

Re: Singleton Pattern in Go

#75

Post by maxlybbert »

Manishearth wrote: post #26
skrap wrote: post #18

Earlier quoted context omitted.

Totally! I was going to post the same thing. Double-checked locking is either impossible or really hard to get right, depending on the language and architecture's guarantees! If you must use a singleton, I'd really recommend doing the so-called "aggressive" approach, which should have really been named the "actually won't crash sometimes" approach.

On C++ if we're using a bool as the "check" and pthread_mutex_lock on a regular mutex would that work, or do we still need to hardcode fences? (Asking because this pattern is used by libcxxabi code)

A few years ago, the C++ standard didn't guarantee that the double-checked idiom would work. Even if your threading library had some way to insert the necessary memory barriers, it was possible that your compiler would optimize important things away.

C++11 changes that. The language now has standard ways to add memory barriers, and compiler optimizations can't remove them.

Re: Singleton Pattern in Go

#76

Post by readme »

Lorento wrote: post #70
readme wrote: post #65

Earlier quoted context omitted.

Nailed it. It's fine to use a singleton, but don't call it from within every class you use it in. Just pass a reference to the instance of the singleton. Call it once in the outermost scope.

Just wondering what value the singleton provided if you only obtain it once. Isn't the purpose so you can obtain it whenever you want? If you just use a regular object, you run the risk of accidentally making another instance somewhere else, but you always have that risk with any regular object anyway.

It's kind of OK to use, as long as you don't call it all over the place and render your code untestable such that it can't be mocked out, but I'm not a huge fan of it. It's really a matter of opinion at that point.
Post reply on HN