Skip to content
Jan Lukavský edited this page Jun 14, 2017 · 6 revisions

Isn't this same thing as Apache Beam? What are the differences?

Indeed, Euphoria and Apache Beam are trying to solve the same type of problems. Both are trying to unify batch and stream processing, and both are trying to abstract away the execution engines from a user code making such programs executable on different engines. However, both projects have independent origins.

As the for the differences:

  • The most obvious difference is the API itself. Euphoria strives for a minimal, readable, easily extensible, and a Java 8 supportive API.
    • minimal: Euphoria provides only a couple of operators.
    • readable: Euphoria does not advertise the fluent style by default, i.e. fluent operator chaining, though it definitely is possible - see euphoria-fluent. We believe that seeing type information explicitly in a program makes its maintenance easier.
    • easily extensible: Euphoria designed operators in such a way that their re-use to create new, use-case specific operators is supposed to be easy. This further supports the requirement of readability. In fact, there is only a handful of operators which must natively supported by back-ends. All others are built from these.
    • Java 8 supportive: Euphoria pays attention to in its client API to support lambda expressions available as of Java 8 as much as possible. This contributes again to readability due to shorter code expressions while still maintaining type safety.
  • All Euphoria back-ends are supposed to guarantee the same semantics. We maintain a central test suite which all Euphoria back-ends have to pass.
  • Unlike Beam, it does not try to come with its own de-/serialization abstraction. It leaves this aspect intentionally to be environment/engine specific.
  • Unlike Beam, Euphoria does not support Python and is not very likely to support it.
  • Euphoria currently does not support side-inputs/-output (feature request #124).
  • Euphoria does not support [Meta]data driven triggers. (feature request #140)
  • Unlike the Beam model, Euphoria currently does not support the Accumulating and Accumulating & Retracting refinements to early emitted values.
  • Euphoria has a concept of attached windowing which has the semantics that once you define a windowing in your data processing chain, the same windowing will be applied to all downstream stateful operations, unless you manually change it
Clone this wiki locally