I quickly scan the book it is suggested "Walnut" but I didn't grasp why, or how E is "secure" somebody can help?
E is written by Mark Miller and is based on "capability theory". In E you can prove a piece of code is safe and capabilities are more explicit.
E Programming Language: Write Secure Distributed Software
11–20 of 22 posts
Re: E Programming Language: Write Secure Distributed Software
#12C and C++ are both powerful languages but D brings some new things to the table. Then there's E, innovative yes, but why use E when we have F, or better, F#? Personally, I've used G for a couple years now but I am betting the future on the H language. Some people are already skipping ahead to using K, but the guys I'm most scared by are those who only use R.
Re: E Programming Language: Write Secure Distributed Software
#13Wasn't E a somewhat popular Amiga PL?
Re: E Programming Language: Write Secure Distributed Software
#14AmbientTalk took it a few steps further, with a concept of near and far references, future pipelining, reflection etc.
edit: Oops, E already had near/far references and promises. AmbientTalk does add more on the reflection/meta-programming side of things and features for mobile ad-hoc networks such as object discovery.
Re: E Programming Language: Write Secure Distributed Software
#15[0]: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... [1]: http://javascript.crockford.com/
Re: E Programming Language: Write Secure Distributed Software
#16Earlier quoted context omitted.
E is written by Mark Miller and is based on "capability theory". In E you can prove a piece of code is safe and capabilities are more explicit.
How do these proofs work if code has IO? For example, if I read a number from the command line, how can I know that it's within a certain range? I'm only very familiar with this type of thing through languages with explicit IO (Idris, F* to an extent), so I'm interested in seeing how it works in languages with implicit side effects.
Effects like I/O have to be explicit: code that wants to do I/O has to be passed an object that can do I/O, it doesn't get any such objects by default at the time it's loaded. Besides this means of control ('capability security') there's also an 'auditors' mechanism for static analysis, e.g. to require some code to have no side effects.
(I'm not endorsing the GP comment; it's not how I would've phrased things. The auditing mechanism does enable proofs, but it was relatively new and experimental, compared to the core capability-security ideas.)
Re: E Programming Language: Write Secure Distributed Software
#17Outside of its security model, E is an interesting language to study because of its actor/object system. Objects live in 'vats', an actor with a local stack and an event loop thread/process. Objects can sequentially/locally communicate with each other in the same vat, but have to communicate as actors between vats. AmbientTalk took it a few steps further, with a concept of near and far references, future pipelining,…
Re: E Programming Language: Write Secure Distributed Software
#18Outside of its security model, E is an interesting language to study because of its actor/object system. Objects live in 'vats', an actor with a local stack and an event loop thread/process. Objects can sequentially/locally communicate with each other in the same vat, but have to communicate as actors between vats. AmbientTalk took it a few steps further, with a concept of near and far references, future pipelining,…
The near and far references and promise pipelining were already in E, unless I'm misunderstanding -- I've only read one paper on AmbientTalk.
Re: E Programming Language: Write Secure Distributed Software
#19C and C++ are both powerful languages but D brings some new things to the table. Then there's E, innovative yes, but why use E when we have F, or better, F#? Personally, I've used G for a couple years now but I am betting the future on the H language. Some people are already skipping ahead to using K, but the guys I'm most scared by are those who only use R.
I'm disappointed that we have more letters to go before we get to the best language ever developed. I'll probably be retired by then.
Re: E Programming Language: Write Secure Distributed Software
#20For what it's worth, capnproto's RPC protocol is based on this. ( https://capnproto.org/rpc.html )
https://sandstorm.io/about#advisors
Cap'n Proto is very much E's distributed programming concepts "ported" to other languages, and Mark helped me get the details right.
Interestingly, E takes a very different approach from standard distributed systems practices today. Most distributed programming today emphasizes stateless servers performing idempotent operations on a monolithic datastore. Stateful servers are considered too hard to get right. What E did is actually provide the vocabulary needed to be able to reason about stateful servers, so you could get them right. Stateful servers are able to achieve massively better performance, especially in terms of latency, because they don't need to hit persistent storage for every single operation. You obviously need some way to deal with machine and network failures, but E provides that.