Compare to other products and languages

NOTE This is FUTURE feature comparison. 90% of this is NOT implemented now

*-coffee-script

• | || & && operators are dropped. Use or, and. You can apply it to bool or int type. Semantics is detected over type inference.
• await defer is good but streaming is much more powerful.
• + a is not valid syntax. You must write prefix unary operators + and - with no space to next
  • Reason multiple sences of a + b
• a?b operator removed. Use a?:b syntax a ?: b and a ? : b are valid too
  • Reason multiple sences of a ? b:c
• a?b:c ternary operator is available. But
  • You can't use it multiline (use if-then-else instead)
  • a? b:c is invalid because can be understanded in multiple sences
• bracket-less function call with ? opetator not allowed so a? b is not valid. Use a?(b)
  • Note that a?.b c is still ok
  • Reason multiple sences of a? b:c

GridGain

• SS is not ACID by default, and SS has no rich distributed primitives for syncronization.
• SS is not Java-friendly by default.

Akka

• In SS function is not Actor. Multiple functions can be fused in single function.
• You can't send message to function without specifying connection. Function doesn't have email for recieving messages.
• You can see message queue in reciever function, but it's not recommended as common practice.
• You can expose API explicit and say "this is an Actor".
• You can specify named probes for test purposes.
• Actor per request is bad practice.
  • You can't monitor this case properly. You need save and look history of all actor create/destroy.
  • Realm execution policy accepting 2 sec for moving computation node (1 sec for unmount+save, 1 sec for mount on new place)
• Application == topology. You change topology only when you change application or when you want to debug something. No manual topology changes on prod. You can still do it, but SS assumes that topology changes not too often and only due code change (execution plan is also code).
• You can track possibly infinite functions. You can track loop (possible distributed loop deadlock).
• There is no dead letter. You must wrap pipeline in ticketing wrapper so when your tickets dropped you will recieve logs in specific place.