Programming Go, using Unified Modelling Language Diagrams

I have just started using Go (GoLang) and I am finding it a great language. However, after many years of UML and the Object Oriented methods, I find that modelling Go programs (Reverse engineering) is a bit problematic, in that Go Structs contain properties/state, but no methods, and methods/functions that use Structs as parameters (even the ones that do magic so that it makes a Struct look like an object), don't contain methods, or state.

Does this mean I should be using another Methodology to model a Go Program or does UML sufficiently model the language constructs?

Yes I know that if you use methods on the Structs that the behavior of an object in UML can be mapped into Go via a combination of a Struct and a Struct Method, but I am finding this to be wrong, an impedance mismatch in paradigms of sorts.

Is it time for a new (perish the thought!) diagramming technique, for the brave new world where behavior is no longer controlled by an object? can behavior be modeled without reference to the state that it is affecting?

Update:

I am trying Data Flow Diagrams out, to see if they fit better to the paradigm. So far so good, but I think I am going to come unstuck when I model the Methods of a Struct, the compromise in the DFD being that they are treated as Functions.

Go supports inheritance!!! arghhh!!! (head is blown clean off.) you can compose a Struct which is made of another Struct, which has methods, that the Sub Struct now inherits...you getting this? my mind is blown. Means that UML IS valid...fully but it feels dirty.

Go Does not support inheritance, it just appears so. DFD's it is then!

The fact that methods are declared outside the definition of the struct itself should not be significant; it is just a minor syntax difference. The methods belong to the struct type just as surely as if they were inside the braces. (They are declared outside the braces because methods aren't limited to structs.)

The real potential problem with using UML with Go is that UML is normally used with traditional object-oriented design (i.e. class hierarchies), and Go takes a different approach to inheritance and polymorphism. Maybe UML can be adapted to Go's type system—I'm not familiar enough with UML to say—but your design approach will probably need to change somewhat whether you continue using UML or not.

Go is not intended to be used in the everything-is-an-object style of Smalltalk and Java. Idiomatic Go programs generally contain a large percentage of procedural code. If your design process focuses on object modeling, it will not work well for Go.

UML still gives you tools useful for analysis and design of components, interfaces, and data. Go is not an OO language, so you cannot use inheritance, polymorphism, methods, etc. You don't need a new paradigm, you may need an old one: Structured Analysis and Structured Design.

> Go Structs contain properties/state, but no methods, and
> methods/functions that use Structs as parameters (even the ones that
> do magic so that it makes a Struct look like an object), don't contain
> methods, or state.

As you may know, in C++ you can also declare methods on structs - just as in classes with the only difference that you won't be able to use access modifiers.

In OOP languages you declare methods of a class inside the class definition, giving the feeling that these methods are somehow part of the class. This is not true for most languages and Go makes this obvious.

When you declare something like the following pseudo-code in a traditional OOP language:

class Foo {
    public function bar(x int) {
        // ...
    }
}

the linker will export a function that will look something like:

Foo__bar(this Foo, x int)

When you then do (assume f is an instance of Foo):

f.bar(3)

you are in fact (and indirectly, more on that later) doing:

Foo__bar(f, 3)

The class instance itself will only contain a so called vtable with function pointers to the methods it implements and/or inherits.

Additionally, methods do not contain state, at least not in the contemporary programming world.

> Does this mean I should be using another Methodology to model a Go
> Program or does UML sufficiently model the language constructs?

UML should suffice.

> Is it time for a new (perish the thought!) diagramming technique, for
> the brave new world where behavior is no longer controlled by an
> object?

Naa.

> Can behavior be modeled without reference to the state that it is
> affecting?

Yes, that's what interfaces are for.

> I am trying Data Flow Diagrams out, to see if they fit better to the
> paradigm. So far so good, but I think I am going to come unstuck when
> I model the Methods of a struct, the compromise in the DFD being that
> they are treated as Functions.

Do not get lost in abstractions, break them. There is no perfect paradigm and there will never be.

If you like planning and modeling more than programming you should just stick with Java.

If you like building and maintaining the actual code and working systems you should try just planning your Go program on a piece of paper or a whiteboard and get programming.