Content
@
0 reply
0 recast
2 reactions
maurelian
@maurelian.eth
https://warpcast.com/eulerlagrange.eth/0x76a7dc How can a new EVM language get past this “cold start” problem? No real usage -> unsafe -> no real usage
7 replies
2 recasts
13 reactions
Dan Finlay 🦊
@danfinlay
Ship small but compelling things on it first. Don’t try to compete with the full Solidity value prop to start. Maybe choose a use case that highlights the language’s strengths over Solidity first.
0 reply
0 recast
4 reactions
pyk
@pyk
make ERC{20,721,..} as audited standard libs, built-in into the language itself
2 replies
0 recast
4 reactions
ross
@z0r0z
Can we uh simulate time passing for a compiler. I know this is a dumb take of mine… but it also seems odd to me that in the realm of code, we have to just, wait for people to do a lot of random things to achieve safety in numbers.
2 replies
0 recast
1 reaction
frangio
@frangio
Bootstrap the language by compiling to Solidity at first. Instruct users of the language to have the Solidity output audited. Gain confidence in the language and grow an ecosystem this way. Eventually develop an EVM backend and fuzz it against the Solidity backend. Pray.
1 reply
0 recast
4 reactions
avi
@avichalp
it is probably going to be a slow start
0 reply
0 recast
0 reaction
Varun Srinivasan
@v
Curious if you have any thoughts on this @gakonst
0 reply
0 recast
0 reaction
chen
@cwkang
I think its pretty difficult to get past the cold start problem. As @danfinlay mentioned, starting small and then slowly increasing the value prop of the language makes a lot of sense. Imo a part of the cold start problem is also caused by the lack of tooling so I would additionally say that focus on providing that.
0 reply
0 recast
0 reaction
