Skip to content

Show HN: Rex, a parallel functional language for scientific workflows

github.com/peterkelly
28 pointspeterkelly8 comments
On HN

Comments

I am curious to see where async would fit. I recognize distributed async is beyond scope for Rex. Given the treatment of content addressable storage (CAS), one could specify workflow states declaratively, poll artifacts for next, and fire tasks to a delegate and then move forward. It would be nice to have a subsystem do that. A question is where parallelism is useful in your scientific workflows, and where it blocks. Quantum chemistry use cases (QDX is behind Rex) are presently beyond me, so I have no idea.

I am thinking that Rex programs are inteneded as an output from a higher level worklow specification language. It would be interesting to see that.

Great work! Will be curious to see how it competes with the existing workflow languages such as Nextflow or Snakemake - do you by any chance have a "Why migrate from Nextflow/Snakemake to Rex" pitch I could read somewhere?

I expected a reference to Dex, but they seem to be unrelated?

https://github.com/google-research/dex-lang

Presumably, not to be confused with Rexx[1]. Namespace collisions ... or perhaps "wrecks".

1. https://en.wikipedia.org/wiki/Rexx.

It was for me and I intended to comment regarding same.

It requires trivial effort to search for prior art before naming something.

OP: Worth doing if you'd like others to invest time lookong at your project.

Yeah but pretty much every name will be taken by something? As long as it's not too close to your new project, I think it doesn't matter that much.

The sample set of programming languages means that every name is most certainly not taken, and every language is too close for identical names for unrelated languages being acceptable.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.