Looks promising and is long overdue. This is along the lines of what Ethereum should have been from its inception. It probably would have avoided many of the highly publicized exploits.
Hopefully carefully considered and well-designed technology will prevail. In this industry we are often too eager to endorse the first-mover as the standard.
Safer coding is important, as are better semantics for state machine processing on chain, where a mistake can be really costly. So, yay.
On the other hand, three things make this hard for me to dig into and get a real opinion: no sample code, so I have no idea if I like the way the authors are going at it, no argument as to why this is not just a solidity extension, and the compiler seems to need java.
It’s my day job to track stuff like this, but I will probably pass until one of those three improves
Looks like it's written in Scala, which is in the realm of ML and quite nice for compilers.
Maybe they could compile w/Scala Native to get rid of the Java dependency? I am not up to speed w/the status of Scala Native or if this project has JVM-specific dependencies though - just a thought :)
If anybody doesn't know about the Mtgox collapse, this man is the reason why creditors haven't seen any money after 6 years and he recently submitted a ~$16b claim against the estate. All the money and coins in the estate are customer deposits yet entitled Mr Vessenes feels he has the right to all of this because he couldn't possibly make money through legitimate business practices.
How bout you recognize customers entitlement to what's left of their deposits?
Is there a language spec and examples anywhere? I can only find one example of what the language looks like in their insurance policy case study paper.
Tezos, which is itself written in OCaml (what originally attracted me to the platform), already has a relatively well design language for writing contracts called Michelson (https://tezos.gitlab.io/master/whitedoc/michelson.html). I say "relatively", compared to the dumpster fire that is Solidity...
Personally, I've always wanted take a look at Liquidity Lang [0] which exists on top of Michelson. At a glance, it seems to solve a large number of issues that have caused bugs in Solidity smart contracts (e.g. liquidity has abstract data types, disallows inline mutation of state, etc)
Why all these new languages? No one really wants to learn yet another language.
The big 4 public dapp blockchains use C++, Solidity and JavaScript. I can't imagine C++ and Solidity is okay. IOST went with JavaScript and the V8 engine for it's smart contracts. That seems the most reasonable as they can leverage a massive amount of JavaScript code.
Will be interesting once people realize they have a way to monetize webapps with a browser extension/wallet. Just think about all the web based JavaScript games that died because no way to monetize. Someone should be porting those over.
Plus, it took IOST only 8 weeks to passed up ETH in total number of blockchain transactions. ETH was launched back in June 2015. IOST has a fast ass blockchain.
From one of their papers the DSL is geared towards non programmers: "The target user base of Obsidian is business professionals who will use the language to write smart contracts, and its design is thus oriented towards this domain. Obsidian programs consist of contracts – similar to classes in Java – which contain fields, states, and transactions – similar to methods."
In another paper they reveal they're also writing an IDE for this, overseen by some PhDs in 'human-computer interaction' so it should be simple to use though I find piles of complexity added by classes/methods the exact opposite of simple.
> though I find piles of complexity added by classes/methods the exact opposite of simple.
I mean, the model of your objects calling methods on other objects (that you don’t control)—and having your methods called by those same objects in turn—is inherent in the abstract machine being programmed for. You don’t have to use express the internals of your program as classes and methods, but that’s how people are going to see your contract “from the outside”, and that’s also how you’re going to have to interact with other contracts.
IOST uses the V8 JavaScript engine to execute it's smart contracts. Seems like a no brainer given the massive amount of existing JavaScript code, tools, and coders.
> Obsidian is currently under development and is not ready for general use. For more details about Obsidian, for now, please read our papers. Want to help? Participate in our user study.
What you are looking for is not in scope for this publication. Keep in mind that this is an academic project.
Agreed, they should have put the code from the paper on the front page:
main contract Policy {
state Offered {
int cost ;
int expirationTime ;
}
state Active {}
state Expired {}
Policy@Offered ( int c , int expTime ) {
-> Offered ( cost = c , expirationTime = expTime );
}
transaction activate ( Policy@Offered >> Active this ) {
-> Active ;
}
transaction expire ( Policy@Offered >> Expired this ) {
-> Expired ;
}
}
Nope both. Holochain core is written in Rust and you code distributed apps ("DNA") in Rust. Polkadot core ("Substrate") is written in Rust and you code smart contracts in Rust ("Ink"). Both compile down to WASM.
Rust does provide some help in its type system (via ownership), but it is not nearly as expressive as Obsidian's. Rust, AFAIK, does not support linearity (i.e. will not warn you when you accidentally lose an owning reference to an object). It also does not directly support typestate (although there are ways of shoehorning parts of that in, I believe).
32 comments
[ 5.9 ms ] story [ 77.0 ms ] threadOn the other hand, three things make this hard for me to dig into and get a real opinion: no sample code, so I have no idea if I like the way the authors are going at it, no argument as to why this is not just a solidity extension, and the compiler seems to need java.
It’s my day job to track stuff like this, but I will probably pass until one of those three improves
http://obsidian-lang.com/publications.html
Looks like it's written in Scala, which is in the realm of ML and quite nice for compilers.
Maybe they could compile w/Scala Native to get rid of the Java dependency? I am not up to speed w/the status of Scala Native or if this project has JVM-specific dependencies though - just a thought :)
How bout you recognize customers entitlement to what's left of their deposits?
You are garbage made flesh.
The last line was unnecessary to get your point across and against HN guidelines.
Also see a draft paper: http://obsidian-lang.com/obsidian-oopsla-19-submitted.pdf
[0] http://www.liquidity-lang.org/
https://cardanodocs.com/technical/plutus/introduction/
The big 4 public dapp blockchains use C++, Solidity and JavaScript. I can't imagine C++ and Solidity is okay. IOST went with JavaScript and the V8 engine for it's smart contracts. That seems the most reasonable as they can leverage a massive amount of JavaScript code.
Will be interesting once people realize they have a way to monetize webapps with a browser extension/wallet. Just think about all the web based JavaScript games that died because no way to monetize. Someone should be porting those over.
Plus, it took IOST only 8 weeks to passed up ETH in total number of blockchain transactions. ETH was launched back in June 2015. IOST has a fast ass blockchain.
"We will target business students and business analysts with limited programming experience, in order to collect data from the intended user base of Obsidian." http://www.cs.cmu.edu/~NatProg/papers/barnaby17%20-%20Obsidi...
In another paper they reveal they're also writing an IDE for this, overseen by some PhDs in 'human-computer interaction' so it should be simple to use though I find piles of complexity added by classes/methods the exact opposite of simple.
I mean, the model of your objects calling methods on other objects (that you don’t control)—and having your methods called by those same objects in turn—is inherent in the abstract machine being programmed for. You don’t have to use express the internals of your program as classes and methods, but that’s how people are going to see your contract “from the outside”, and that’s also how you’re going to have to interact with other contracts.
https://developers.iost.io/docs/en/2-intro-of-iost/VM.html
What you are looking for is not in scope for this publication. Keep in mind that this is an academic project.
https://blockstream.com/2018/11/28/en-simplicity-github/
https://github.com/ElementsProject/simplicity