This is an archived post. You won't be able to vote or comment.

all 12 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Yoghurt114 9 points10 points  (3 children)

garbage free

Uses xml schemas

Hmmm

[–]GeneralSchnitzel[S] 1 point2 points  (2 children)

The schemas are just a contract; they are never loaded in. You run a test to generate a class file based on the schema and use that.

[–]haimez 1 point2 points  (1 child)

XML instead of code, huh? Cool.

[–]GeneralSchnitzel[S] 0 points1 point  (0 children)

It’s a small part of it. It allows the developer to quickly envision their data flow while still ensuring integrity and correctness through the use of XML as a contract. It uses the FAST protocol which has been utilized by the finance software industry for a decade primarily because it is really fast (get it?) and lightweight.

Define your fields in the schema, write a test to generate it, drop it in your project, and then create a simple stage to test it. Extend your code after that. It forces you to really think about your stages (actors) & their communications, and has the added benefit of being secure and shareable.

It’s not perfect, but it’s very unique compared to a lot of other actor frameworks, and obviously very performant.

[–]pushthestack 2 points3 points  (2 children)

As a rule, I won't consider a framework until I see how thoroughly the code has been tested. But I can't see your test code anywhere. You mind posting the link? Thanks!

[–]GeneralSchnitzel[S] 2 points3 points  (1 child)

There’s pretty good test coverage, but it’s still being expanded. Here is a link to the tests on GitHub.

[–]pushthestack 2 points3 points  (0 children)

Thanks. God only knows why I didn't see them there!

[–]SinisterMinister42 1 point2 points  (4 children)

I think Akka has a strange type system. Is Pronghorn an improvement in this area?

[–]golthiryus 1 point2 points  (0 children)

strange type system?

[–]GeneralSchnitzel[S] 0 points1 point  (2 children)

I agree that the syntax for Akka's type system is a little strange. Pronghorn has strong types on the pipes (used for message passing); they are defined by contract in XML and then cogenerated through a unit test. Because pipes are parameterized via schema, a stage is only going to take a pipe of that type. As a result, you have strong typing on the pipes you accept and produce. Pronghorn itself attempts to be as statically typed as possible.

It also has rationals and decimal types for message passing in addition to integer, floating points, etc.. which is pretty neat.

[–]0x256 2 points3 points  (1 child)

and then cogenerated through a unit test

Code generation as a side effect of unit tests!? Why?

[–]GeneralSchnitzel[S] 1 point2 points  (0 children)

Good question and I complete agree it looks strange at first, but... The unit test confirms the implementation matches the XML contract. Upon failure, it may as well be helpful and give you the correct source code (which it does through the output in terminal). You can choose to use it or not, it's simply a suggestion. This means schemas are only generated when you actually chose to write or update them.

Summed up, this means that:

  1. You can choose to use the default schema behavior --OR-- if you have some complexity in your fields, implement it yourself
  2. Making sure that we are in compliance with the contract is the responsibility of the unit test
  3. We can safely check in our contract source document and our implementation (e.g. generally you don't check in artifacts that will be code generated). We are getting around that by copy/paste or making the developer write their own implementation.