3 ms·

Okay? But when is somebody going to fix the documentation and keep it in sync with the language's development? I've never once had a problem with Go's document

Okay? But when is somebody going to fix the documentation and keep it in sync with the language's development? I've never once had a problem with Go's documentation and it started out as a relatively casual project that is more peripheral to Google's interests than Servo is to Mozilla's. Making a language be able to get picked up by the wider programming community means somebody has to spend time on things other than the compiler. Lots of time.

pcwalton 13y ago
I don't disagree. The documentation needs work. That said, the compiler needs a lot of work as well, as those who have used the language for any amount of time can attest to. Everyone sees the dreaded "internal compiler error" message. Everyone encounters borrow check and code generation bugs. Everyone misses a working package management system and pretty printer. Everyone bemoans the slowness of compilation for small programs. These are things you just didn't see for Go when it was announced--because it was Google-internal then. We intend to fix the documentation before calling it 1.0. But compilers are complex, especially for a language with a rich type system and a nontrivial static analysis built in (the borrow check). There are many things to do, from documentation to bug fixing to feature work (macros and default methods are unfinished) to tooling work. Note, however, that the code examples in the documentation are kept up to date and enforced via the test suite. So there may be inaccuracies in the prose, but we do perform automated quality control as best we can.
- codewright 13y ago
  Good to know. The package management is going to be particular interest to me.
steveklabnik 13y ago
I specifically will be devoting lots of time to Rust's documentation, but I've been waiting for the syntax changes to settle down. 0.6 fixed a lot of that.

pcwalton 13y ago

I don't disagree. The documentation needs work. That said, the compiler needs a lot of work as well, as those who have used the language for any amount of time can attest to. Everyone sees the dreaded "internal compiler error" message. Everyone encounters borrow check and code generation bugs. Everyone misses a working package management system and pretty printer. Everyone bemoans the slowness of compilation for small programs. These are things you just didn't see for Go when it was announced--because it was Google-internal then. We intend to fix the documentation before calling it 1.0. But compilers are complex, especially for a language with a rich type system and a nontrivial static analysis built in (the borrow check). There are many things to do, from documentation to bug fixing to feature work (macros and default methods are unfinished) to tooling work. Note, however, that the code examples in the documentation are kept up to date and enforced via the test suite. So there may be inaccuracies in the prose, but we do perform automated quality control as best we can.

codewright 13y ago
Good to know. The package management is going to be particular interest to me.

steveklabnik 13y ago

I specifically will be devoting lots of time to Rust's documentation, but I've been waiting for the syntax changes to settle down. 0.6 fixed a lot of that.