[SystemSafety] C for OSs

[Peter Bishop]

I have run across this language.

  * It is a declarative style language (bit like Prolog).
  * It does have garbage collection
  * But there are quite fast implementations (approaching C speeds)

Erlang language features

  *
    Built for concurrency
  *
    Can have thousands of concurrent lightweight processes
  *
    Erlang run-time transparently assigns processes to available cores
    in a multicore processor
  *
    Good error handling (closedown of linked processes)

There is also the Erlang Open Telecom Platform (OTP)

  *
    Written in Erlang
  *
    Includes Mnesia database (pun intended!)
  *
    Data can be replicated on multiple nodes
  *
    Can have different database segments on different sets of nodes
  *
    Ensures data integrity and resilience to processor failure

Erlang and OTP have been used for a high dependability financial fund
transfer system
While the system can handle a high transaction rate, I would not regard
the application as hard real time.

Regards

Peter

On 09/09/2019 11:42, David Crocker wrote:
> I don't know Erlang, but I understand that it uses garbage collection
> (like most programming languages that are nice to program in). Doesn't
> that render it inappropriate for building hard real-time systems?
>
> David Crocker, Escher Technologies Ltd.
> http://www.eschertech.com
> Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486
>
> On 08/09/2019 21:43, Olwen Morgan wrote:
>> All,
>>
>> Forgive me for multiple postings but ideas are occurring to me in fits
>> and starts on this one.
>>
>> Given a free hand to choose a language running on an x86_64 target for
>> implementing a highly concurrent critical system, I'd almost always go
>> for Erlang, whose track record at Ericsson is mind-bogglingly good. Of
>> course, the BEAM Erlang abstract machine needs a hosted environment in
>> which to run. One helpful development in this area is the GRiSP2,
>> single-board hardware abstract machine for Erlang/Elixir. This gets
>> rid of UNIX but still leaves dependency on an relatively
>> low-availability hardware.
>>
>> Now, if someone could implement a true bare-metal BEAM for x86_64
>> (possibly only a smallish step farther?), you wouldn't need
>> special-purpose boards ... and I could die happy ...
>>
>> ... but not yet ... (in case those of you who'd be glad to see the
>> back of me are rubbing their hands with glee) ... :-O
>>
>>
>> Olwen
>>
>>
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> Manage your subscription:
>> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-- 

Peter Bishop
Chief Scientist
Adelard LLP
24 Waterside, 44-48 Wharf Road, London N1 7UX

Email: pgb at adelard.com
Tel:  +44-(0)20-7832 5850

Registered office: 5th Floor, Ashford Commercial Quarter, 1 Dover Place, Ashford, Kent TN23 1FB
Registered in England & Wales no. OC 304551. VAT no. 454 489808

This e-mail, and any attachments, is confidential and for the use of
the addressee only. If you are not the intended recipient, please
telephone 020 7832 5850. We do not accept legal responsibility for
this e-mail or any viruses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190909/adae8990/attachment-0001.html>