CreatCodeBuild
commented
4 years ago I learned about Transducer from Clojure last year or early this year. Found this is the only attempt in Go. Reading your words feels like traveling in a time machine. Now it's 2020, do you think it would be feasible to have transducer in Go when generics are finally introduced in Go?
I am researching this topic again because I recently discovered Go+, a syntax extension of Go attempting to suit data science.
As a runtime, Go is very performance, therefore naturally people want to run computation-intensive applications in Go runtime. However, Clojure is fundamentally dynamic while Go is a very static language. I doubt Go is ever gonna be friendly to functional-style programming.
Since Clojure is designed to be hosted language, I wonder if a Clojure to plan9 assembly compiler can be written so that we can use Clojure to interface with Go ecosystem.
Generics: the question the just keeps coming up. Developing this library has evolved my perspective a bit.
I've worked on a couple libraries that traffic in generics, and looked at a lot more. The most practical problem, IMO, is the cost/benefit of having to constantly type-assert values as they emerge from your generic datastructures. The secondary problem is a consistency one - that all the elements in a given datastructure would be of the same type. This guarantee is lost when relying on
interface{}.Both of these problems would be solved with parametric polymorphism; however, it's my understanding that the Go authors feel that the benefits of doing this are minimal, given that the ease of either performing the check yourself with a type assertion, or just making a type-specific version of the library. In general, I'm inclined to agree.
With transducers, however, fully and correctly typing transduction processes is about much more than just parametric polymorphism. Frankly, I don't understand all the gymnastics a type system would have to perform to bring type safety to a system like transducers; I know that an algebraic type system would help with some problems, some noise about rank-2 polymorphic types, and then some more stuff here.
In writing this lib, I've observed that whereas problems that are solveable with parametric polymorphism often don't feel "worth it" in Go, it gets a lot more appealing when the use of
interface{}is eliding more complex type issues. Transducers provide a way of subdividing and organizing whole segments of an application - maybe that's worth a bit of the "run time type safety" mentality. Or maybe it's an even bigger reason not to use them - that the types that emerge from a transduction pipeline could be so unpredictable.