Google's Go language has one of the spiffiest toolchains around, with fast, one-step compilation to native platform binaries. But for some developers, the Go language is too opinionated -- or limited -- to make the switch worthwhile.
A new project is attempting to address this by creating an experimental language for Go's ecosystem and toolchain, in the same way that languages like Clojure, Groovy, and Kotlin have been built for the Java Virtual Machine.
The new language, named Oden, is inspired by Go, but also by Haskell and Lisp. Oden aims to use Go's "static linking, cross-compilation, goroutines, channels, and the great set of libraries and tools," but it provides features the Go language doesn't have yet, such as higher-level abstractions, polymorphism, and a safer yet more flexible type system.
That "safer yet more flexible type system" is one of the most prominently discussed features of Oden so far. Many languages -- such as Python -- allow polymorphism, which is the ability for a single function to take data of multiple types. Go doesn't support it directly; and while it's possible to work around this limitation via Go's interfaces, it's still just a workaround.
Oden, by contrast, aims to provide true polymorphism for functions. It's also designed to allow other features in this vein that Go doesn't have, like type inference.
Another major difference Oden has targeted is error handling and checking for nil (aka null) types. Go's error handling has been criticized for being not robust enough by those used to mechanisms like Python or Java exceptions. Oden's stated long-term goals in this area include "higher-level abstractions for error handling [and] nil checking," although there are so far no details about how this will be implemented.
Many of Oden's other proposed features are common to modern programming languages, such as immutable data structures, which are found often in functional languages; pattern matching, which is a feature used in the Rust language for handling control flow; and interoperability with Go's existing types and features.
All this comes with one big caveat: The project is still very new and likely to change drastically as it develops, so it'll be a long time before anything production-ready can be built with Oden.
Even if Oden doesn't take off, the project is proof that Go's toolchain can be a launchpad for languages that don't necessarily owe anything to Go directly. This is akin to the JVM and .Net systems, both of which spawned languages not based on Java or C# but which could leverage the wealth of code already written for them.
Compared to the amount of Java code that can be used by JVM languages, there isn't as much Go code for Go-based languages to plug into. But the underlying idea is sound. And now that Go has been out for six years or more, it's ripe enough for experiments like this one to have a strong chance of flourishing.