Golang is not meant to be DSL friendly language like Haskell. It is still possible to use Golang to implement DSL such as http/Template package which parses the input (template) and fills the template with values from golang langueage. This can be used for example in simple Email templating or even implementing SSI type of html pages. text/Template package implements parser that reads the template and calls the Go language part defined in {{}}.
DSL can be characterized to Internal and External DSLs languages. Internals extends langauge with approprieate constructs to specialized to problem domain such in QML. Golang does this in the sense that there is channel syntax <- easing communication easier with goroutines. Second category: External DSLs is more interesting as it provides more flexibility in the language and broading the effective problems domains that are not part of original Golang design. Golang features are lacking in this respect manyways. Latest version of Golang present plugins architecture that runs in process making possible at runtime extend functionality by loading libraries and casting interfaces to internally in library.
There is also possibility interact between components using RPC where different parallel/sub processes are specialized to different tasks. Separate processes can be implemented over system boundary using local or remote sockets and common datatypes. This model is flexible and robuest but doesn't provide low hanging fruits without appropriate framework on top of Golang. One interesting framework implementing this kind of functionality is Hashicorp Golang plugin.
So far discussion about Golang using everywhere doesn't look very promising. It is good language and very effective in certain networking domain with parallelism and IO streams, not very flexible at the moment with Everything. I personally think that one way to extend language is to utilize plugins. Golan provides quite good interaction with C already. It would be nice to see Similar interaction provided to some DSL specialized language. There are suitable languages for DSL designing like Haskell; with support of RPC and thrift/protobuf provides interoperability with Golang to some external extent. Haskell is generic language that can be used to make DSL but there are also specialized languages such as Xtext and Jetbrains MPS that are designed to make DSLs. Domains in specialized languages can vary as well. There is no single solution fits all purpses. In my opinion one of the best use case for Golang DSL would be specify network components integration language; similar that i've started in txmachinae repository.
When thinking DSL, there is beside internal and external, other ways to think DSL as well; meaning parsed or ast. Languages are typically parsed; for example in Golang <- denotes channel. This makes Golang syntax. Other way to think language is the result of the parsing: AST which is computer way to see the language. DSL can be seen expert lanauge with more freedom to express solution to certain problem with a specific notation; for example Math symbols instead of ascii characters. It is also common to provide layer on top of parsed language that extend the basic language with symbols and constructs from other problems solving domains as far as those are compatible with base language types. Most common way to do this C compiler pre-compiler. Computer IDEs can do lot more than that nowdays. Including UML state machines and decision trees. Jetbrain MPS is one good example and that might be appliable directly to Go. DSL could be utilized on top, beside and below Golang. Graphically or having textual re-presentation. The fesible solution all depends what is tried to achieve. Channels and streams gives good starting point but the problems domain lnguage needs clear way make use of these constructs. Clear way to use langauge constructs would make writing DSL AST/Parsers more easy starating point. No need to guess how to use channels on different specific situation.
Obvious solution to implement DSL with Golang would be using CGo. Use Go to call C function that calls Haskell function. Result would be C type or socket for communication and streaming. Ducktape ie. Golang/channels|mutexes/Goroutine/CGo/
When I said Golang is not DSL frienly language; that was not perfectly true. Golang provides different methods to being generic. Methods like reflection, interfaces and tooling for code generation. go generate was introduced and that can be used to instruct processing source files. Most simple example is using sed to modify type names in files and use those as sort of generics. Golang also provides go/ast package to parse syntax trees from files.. So it is kind of quite DSL frienly from toolchain point of view. The philosophy is just different; like composition (~declarative) over inheritance. In the sense generataing source files is declarative (and probably recommended) way to provide generics or implement metaprogramming concepts. I was stubmled some related projects such goast etc. Using golang as metalangueage has one significant advantage; not depending third party languages or plugins.
Improve goroutine synchronization by providing implied Context and extend SELECT statement with optional CASE This syntax would make possible to guard case clauses with notation that denote if other conditions have been met and only then this would be active case. Use case would be synchrinizing multiple goroutines with clear and expressive syntax.Versioning
Aliasses