[erlang-questions] Erlang for Payment Systems

[Drew Varner]

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.

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. 

> On Apr 30, 2016, at 11:52 AM, Garrett Smith <g@REDACTED> wrote:
> 
> Decoding data received on the network does not sound like string
> manipulation - but data decoding. This is one of Erlang's strengths.
> 
> Once decoded, transforming data and generating string like output
> (e.g. encoding JSON or XML) can be both very fast and memory efficient
> - it depends on what you're doing as programmer.
> 
> There's nothing about Erlang that's particularly weak in these areas -
> certainly not to ward you off without specifics.
> 
> I'd say that Erlang's glaring weakness wrt other language options is
> lack of static typing. However, this comes with the benefit of hugely
> simplifying distribution. That's a deliberate trade off that's been
> made in this language. There are ways to mitigate the language's lack
> of static typing (e.g. see TypEr and Dialyzer).
> 
> Also consider that there are classes of bugs that cannot be detected
> by static type checks. And even if you code is bug free (good luck)
> your code has nothing to say about hardware failure. You need a system
> that reaches outside your program, which means distribution of some
> sort.
> 
> What you're describing is a critical, long running, unattended system.
> Those are really hard to build and you should put a premium on tools
> and languages that help you build them successfully (i.e. they
> actually do what you want at acceptable service levels) at low cost.
> You'll be hard pressed to find a better language environment along
> these lines than Erlang.
> 
>> On Fri, Apr 29, 2016 at 3:09 PM, Hassan Sowwan <h_sowwan@REDACTED> wrote:
>> Hello,
>> 
>> I am trying to implement payment messaging middleware and would like to
>> explore the option of using Erlang/OTP.
>> 
>> The application will be used in banking industry to interface with EFT
>> payment switch/networks and core banking system to process card
>> transactions.
>> 
>> It will be responsible to perform following tasks:
>> 
>> 
>> Communicate with external interfaces using ISO 8583 messaging format ( thru
>> TCP/IP)
>> Receive huge amount of data over the socket ( HEX, BINARY, EBCIDIC), which
>> represents financial transactions.
>> Parse/decode the received data.
>> Perform some checking in database for validation
>> Interface with host security module to validate customer PIN and other
>> security checks.
>> Sends the request to core banking system via XML or web services call
>> Respond back to external interfaces by formulating the response message in
>> ISO 8583 format
>> 
>> 
>> Obviously, such applications have to be concurrent and fast enough to
>> process transactions within few seconds.
>> 
>> Now my question here, is Erlang a good choice for implementing this type of
>> applications ?
>> Can Erlang handle string processing efficiently without impacting the system
>> performance?
>> As stated before, there will be a lot of string manipulation to decode data
>> received over the network, so I am not sure whether erlang fits perfectly or
>> not.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions