<div dir="ltr"><div>something else you might also want to  look into is pcidss and padss security requirements.<br></div>you will be required to comply with these requirements if you intend to communicate with visa,mastercard and other international payment schemes .<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 30, 2016 at 6:32 PM, Drew Varner <span dir="ltr"><<a href="mailto:drew.varner@redops.org" target="_blank">drew.varner@redops.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Joe's #2 goal of correctness and Garrett's use of success typing (Dialyzer and type specs) naturally point to property-based testing. Erlang QuickCheck (EQC) and other property-based testing frameworks provide additional confidence in the code.<br>
<br>
Specifically, generators and shrinking strategies work hand-in-hand with Erlang type specs. Basic property-based testing provides a more thoughtful way to test code with solid coverage and the ability to try many edge cases that a developer may have missed in traditional unit tests. Advanced property-based testing with stateful models offers the opportunity to uncover elusive concurrency errors that typically show up in obscure bug reports. If I were playing with money in an Erlang program, I'd leverage these tools.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Apr 30, 2016, at 11:52 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br>
><br>
> Decoding data received on the network does not sound like string<br>
> manipulation - but data decoding. This is one of Erlang's strengths.<br>
><br>
> Once decoded, transforming data and generating string like output<br>
> (e.g. encoding JSON or XML) can be both very fast and memory efficient<br>
> - it depends on what you're doing as programmer.<br>
><br>
> There's nothing about Erlang that's particularly weak in these areas -<br>
> certainly not to ward you off without specifics.<br>
><br>
> I'd say that Erlang's glaring weakness wrt other language options is<br>
> lack of static typing. However, this comes with the benefit of hugely<br>
> simplifying distribution. That's a deliberate trade off that's been<br>
> made in this language. There are ways to mitigate the language's lack<br>
> of static typing (e.g. see TypEr and Dialyzer).<br>
><br>
> Also consider that there are classes of bugs that cannot be detected<br>
> by static type checks. And even if you code is bug free (good luck)<br>
> your code has nothing to say about hardware failure. You need a system<br>
> that reaches outside your program, which means distribution of some<br>
> sort.<br>
><br>
> What you're describing is a critical, long running, unattended system.<br>
> Those are really hard to build and you should put a premium on tools<br>
> and languages that help you build them successfully (i.e. they<br>
> actually do what you want at acceptable service levels) at low cost.<br>
> You'll be hard pressed to find a better language environment along<br>
> these lines than Erlang.<br>
><br>
>> On Fri, Apr 29, 2016 at 3:09 PM, Hassan Sowwan <<a href="mailto:h_sowwan@hotmail.com">h_sowwan@hotmail.com</a>> wrote:<br>
>> Hello,<br>
>><br>
>> I am trying to implement payment messaging middleware and would like to<br>
>> explore the option of using Erlang/OTP.<br>
>><br>
>> The application will be used in banking industry to interface with EFT<br>
>> payment switch/networks and core banking system to process card<br>
>> transactions.<br>
>><br>
>> It will be responsible to perform following tasks:<br>
>><br>
>><br>
>> Communicate with external interfaces using ISO 8583 messaging format ( thru<br>
>> TCP/IP)<br>
>> Receive huge amount of data over the socket ( HEX, BINARY, EBCIDIC), which<br>
>> represents financial transactions.<br>
>> Parse/decode the received data.<br>
>> Perform some checking in database for validation<br>
>> Interface with host security module to validate customer PIN and other<br>
>> security checks.<br>
>> Sends the request to core banking system via XML or web services call<br>
>> Respond back to external interfaces by formulating the response message in<br>
>> ISO 8583 format<br>
>><br>
>><br>
>> Obviously, such applications have to be concurrent and fast enough to<br>
>> process transactions within few seconds.<br>
>><br>
>> Now my question here, is Erlang a good choice for implementing this type of<br>
>> applications ?<br>
>> Can Erlang handle string processing efficiently without impacting the system<br>
>> performance?<br>
>> As stated before, there will be a lot of string manipulation to decode data<br>
>> received over the network, so I am not sure whether erlang fits perfectly or<br>
>> not.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>