To implement an efficient dataflow-based programming API/DSL, you better have some support for channels and lightweight threads in a scriptable language, something that you've got in Groovy with the GPars library that Nextflow uses.
We opted for implementing all of this in Go in SciPipe, where we get similar basic dataflow/flow-based functionality as Nextflow with the native concurrency primitives of Go, but the Go syntax probably/surely puts away some biologists who have written some python at most before, and Go won't let us customize the API and hide away as much of the plumbing under nice syntax, as Groovy.
In this regard, Groovy with the GPars library for the concurrency, doesn't seem as a particularly bad choice. There weren't that many options at the time either.
The downside has been tooling support though, such as editor intelligence and debugging support, although parts of that is finally improving now with a NF language server.
Today, one could probably implement something similar with Python's asyncio and queues for the channel semantics, and there is even the Crystal language that has Go-like concurrency in a much more script-like language (see a comparison between Go and Crystal concurrency syntax at [1]), but Crystal would of course be an even more fringe langauge than Groovy.
We opted for implementing all of this in Go in SciPipe, where we get similar basic dataflow/flow-based functionality as Nextflow with the native concurrency primitives of Go, but the Go syntax probably/surely puts away some biologists who have written some python at most before, and Go won't let us customize the API and hide away as much of the plumbing under nice syntax, as Groovy.
In this regard, Groovy with the GPars library for the concurrency, doesn't seem as a particularly bad choice. There weren't that many options at the time either.
The downside has been tooling support though, such as editor intelligence and debugging support, although parts of that is finally improving now with a NF language server.
Today, one could probably implement something similar with Python's asyncio and queues for the channel semantics, and there is even the Crystal language that has Go-like concurrency in a much more script-like language (see a comparison between Go and Crystal concurrency syntax at [1]), but Crystal would of course be an even more fringe langauge than Groovy.
[1] https://livesys.se/posts/crystal-concurrency-easier-syntax-t...