Production ready?

[yograterol]

Hi,

Is Viper production-ready?

[beaugunderson]

@yograterol it might help to define the characteristics that would make a language production-ready for you :)

[yograterol]

@beaugunderson of course, I want to know if Viper is mature and if I should use Viper over Solidity in new projects. I think the answer is yes, but I would want to be sure. Thanks

[vbuterin]

I would say not yet; I advise playing around and building things on it, but waiting for a security audit before releasing serious projects that deal with money on top of it.

[yograterol]

I would close this issue, we could add it message to the README.

[fubuloubu]

One aspect of production ready is being feature-complete for a release candidate to perform the audit on. There are still 1-2 unimplemented features I think? #297, #295

Next I would say is functional testing. I don't think we have a set of tests that visibly proves the main features are correctly implemented. We need this to ensure that subsequent releases don't break currently provided features. I wanted to work on that. 100% coverage testing is somewhat important too, being a compiler, but I wouldn't argue vital at this point.

Besides a security audit, I would also argue a user experience audit would be nice to ensure all error messages are clear and precise and the language grammar is clear, easy to use, and well-documented.

Thoughts?

[yograterol]

@fubuloubu you've some points.

#297 and #205 are required features to a complete implementation of some smart contracts.

The 100% tests coverage is a MUST to the first release.

Security and UX are important too, in the doc I will add all error messages from that point the community will be able to make proposals to change it.

I propose this milestone to reach the version 1.0 BETA

• 100% documentation - @DavidKnott
• 100% test coverage or at least > 95% quality tests. - @fubuloubu ?
• Release What should the syntax for (i) ABI-formatted logs, and (ii) calls to external contracts be? #297 and Improve and thoroughly test gas estimation #295.
• Improve installation process.
• Create a landing page for Viper - @vbuterin do you have some domain name for VIper?
• Security Audit <- We need help in it. May be @Dexaran could help.

Why Beta?

Because I believe Viper needs to have #296 (Debugging tool) to reach 1.0.

[fubuloubu]

100% functional tests written/passed, 95% coverage (coverage is hard lol)
Functional tests need requirements, is there a good resource for the exact requirements? I only know about the following as a specific language features (besides the clearer syntax):

• gas estimation
• overflow/bounds checking

IMO security audit and UX audit isn't required for a beta. This language compiles to bytecode, so you don't HAVE to put it into to deploy a real contract to prove that ethereum integration works. Asking people to play with viper on testnet should be the beta phase (getting comments, bugs, etc. as a result). I would say don't trust viper with real money until 1st release (not beta), which we make the security audit a necessary gate to (for 1.0.0-rc) so you don't have to redo that work. A quick breeze-through to make sure nothing we're doing is inherantly unsafe is nice though.

Landing Page, use GitHub docs? Does it need something more complicated than a show of the docs and some examples?

[fulldecent]

Please create an objective criteria for closing this issue. I propose:

• Identify all issues blocking a 1.0 release
• Create those issues
• Add a 1.0 milestone, add those issues
• Close this issue

[fubuloubu]

Closing this issue, other issues blocking the first 0.1.0rc1 are being tracked here: https://github.com/ethereum/vyper/projects/6