Never? That seems a little extreme, no? It's a tool like any other and IMO, it's a sometimes useful idiom that works pretty much identically in Go as it does in other imperative languages. However, I'd be interested in any links you could provide which might elaborate on why a factory is never an optimal solution.

If you know what type you need, why would you need a factory to create it for you? Just create it.

I already explained why. The Factory abstracts away instantiation and configuration details for a complex or dynamic initialization process. I understand you don't agree with that approach, but it's fairly common.

(see page 5) http://www.cs.colorado.edu/~kena/classes/6448/f07/lectures/2...

(see accept answer) http://programmers.stackexchange.com/questions/81838/what-is...

but there's pretty much never a reason to have a function create a variety of types for you.

The capability to define a function's return type to as an interface type would suggest otherwise, but we'll have to agree to disagree in that regard. :)

Is there some reason you can't do that by just having this?

  func IntializeFoo(f *foo)

Uh... if you know what type the function is returning you, why do you need it to return an interface? You don't need the interface until you pass it into a function that requires an interface, at which time, the type you've made will be converted for you... why convert before you need to?

Either the consumer should never need to know about types, in which case, you should probably just make it an enum:

  type ServiceType int
  const (
      Weather ServiceType = iota
      News    ServiceType
  )

  type Service interface {}

  func Service(type ServiceType) Service

  func Initialize(svc Service)