We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state channels implementation (implemented in a sibling repo). The concept of TypeScript code generation is very valid, saves a lot of time during rapid prototyping and contracts become self-documenting, with IDE errors after signatures change. Generated contracts are isomorphic and work well from Node.js and a browser while being simply packed with NPM. https://github.com/dbrainio/Soltsice
Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar).
Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it develops further!
Hi! Thanks! I will replace truffle-contract with web3 1.0 contracts API. Current web3 1.0-beta doesn't work well with TS. The dependency was accidental since I was already using it, while writing codegen stuff took very little time and was just a helper script in a contracts repo initially. Our public API is plain async TS, truffle-contract is only an implementation detail.
Need for such solution seems so obvious given that we have Go ABI gen tool for a similar purpose and JS is the main language for DApps (and probably Node.js for backend is more popular than Go). Also, truffle migration looked like a fragile black box, and testing with `jest --watch` instead of truffle suite is much nicer and faster.
I wrote ARCcore.filter to solve many of the issues discussed. And, because it works at the JavaScript function level to normalize/validate function I/O it works well with _everything_ to solve the runtime data problem. And, it opens up a new world of type-based runtime metatemplate programming to JavaScript developers. https://encapsule.io/docs/ARCcore/filter
Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc?
I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.
Formal verification is needed but syntactic sugar is not inherently the problem. The problem is that there a a million gotchas because it looks high level, but isn't.
Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract.
Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly...
I am not equipped to exhaustively lament it as a language, but it is not a pleasant experience.
Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar).
Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it develops further!
Need for such solution seems so obvious given that we have Go ABI gen tool for a similar purpose and JS is the main language for DApps (and probably Node.js for backend is more popular than Go). Also, truffle migration looked like a fragile black box, and testing with `jest --watch` instead of truffle suite is much nicer and faster.
I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.
Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract.
Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly...
I am not equipped to exhaustively lament it as a language, but it is not a pleasant experience.
HN user jatsign shared some of his inital gotchas two weeks ago.