Dual-seat wrap · Sort the Sentence · Seat the Answer · Walk the Ladder · Draft, Then Stop

Sort the sentence. Seat the answer. Walk the ladder. Draft, then stop.

§I. Frame

This is the last Duha row of the V week. Asr #5 wrote the verdict against Rust on three lines this afternoon: memory model, safety guarantees, maturity. Rust won all three. This lesson does not repeat that table. It splits the question into two seats and answers each one alone.

1. The learn and contribute seat. Can Evan read V, run its tools, and send it a small, correct pull request? Yes.
2. The adopt seat. Should any Hedronite product take V as an implementation language? No.

The two answers do not conflict. A project you would not ship on can still be a good place to practice reading a compiler, running a test suite, and writing a clean PR. Source pin: vlang/v tag 0.5.2 (commit 7647ce1). The compare page at vlang.io is a live page and counts as the authors' words.

§II. Four techniques

• Sort the Sentence. Every statement about V goes in one of two bins before it enters a verdict: fact from the pinned tree, or claim from the authors.
• Seat the Answer. Ask "learn" and "adopt" as separate questions. A yes on one never carries over to the other.
• Walk the Ladder. Contribute in the order CONTRIBUTING.md gives: read, reproduce, review, then fix.
• Draft, Then Stop. The lesson ends at PR text. Nothing leaves the lab Mac.

§III. Sort the Sentence

Three facts, each checkable in the 0.5.2 tree:

1. There is no formal spec. docs.md, "Language specification": V "does not yet have a separate formal language specification document like the Go spec." Until 1.0, the compiler and its tests define the language.
2. Breaking changes are still allowed. README, "Stability, future changes, post 1.0 freeze": V is "at an early development stage" and "there will be changes before 1.0." The freeze comes after 1.0, not now.
3. Ownership is optional. ownership.md opens with "V has an optional ownership system inspired by Rust." It sits behind a flag, and the default build uses a tracing garbage collector (Asr #4 lab).

A supporting fact from ROADMAP.md: "Runtime race detector" is still an unchecked box.

Three claims, labelled as claims. They are the authors' words and were not verified here:

1. Claim: "no undefined behavior". README lists it under Safety and marks it "(wip)" itself.
2. Claim: "Fast compilation: ≈110k loc/s with a Clang backend" (README). Asr #5 measured one small program on the lab Mac and found a dev build of 0.22 s; that number says nothing about a loc/s rate, so the claim stays a claim.
3. Claim: the compare page calls Rust "a complex language with a growing set of features and a steep learning curve" and offers V as simpler. That is an opinion about Rust written by V's authors.

If a sentence about V does not cite a file at 0.5.2 or a lab log, it goes in the claim bin.

§IV. Seat the Answer

When V fits (learn and contribute seat):

• Reading a small compiler written in its own language. The whole toolchain builds from one tree, and v fmt, v test, and v doc ship in the same binary.
• Practicing the PR loop on a project that publishes a contributor ladder and a test guide.
• Quick throwaway programs where a C backend and a garbage collector are fine.

When V does not fit (adopt seat), for Hedronite:

• Any core path that depends on memory or thread safety. The safety claims are marked unfinished by the project, and the race detector is still on the roadmap.
• Any code that must survive language upgrades. No spec, and breaking changes are allowed before 1.0.
• Any place where Rust is already in use. Hedronite's core is Rust; moving any of it to V means a rewrite, and the facts above give no reason to rewrite.

Verdict: learn and contribute, yes. Adopt, no. There is no Hedronite product seat for V. No service, library, CLI, or build step in a Hedronite product is written in V or depends on it. The question can be reopened only with new evidence, such as a 1.0 release with a spec and the wip markers removed.

§V. Walk the Ladder

CONTRIBUTING.md orders the work by "easiness/time/nerves investment". Starting tasks come first: read the docs, fix doc errors, write programs, read new issues, reproduce them, review PRs (items 0 to 6). PRs that fix bugs are Medium task 7, "after gathering experience with 1..6". Duha #7 walked this ladder and Duha #8 did one Starting task 2 change locally. The checklist below folds the whole week into five steps.

Contributor checklist (V 0.5.2):

1. Fork. Fork vlang/v on GitHub, add your fork as the pullrequest remote, branch with git checkout -b. Never push to origin.
2. Fmt. v fmt -w on every file you touched, then v fmt -verify must exit 0.
3. Test. Run the nearest _test.v with v test <dir>. TESTS.md asks for v test-all before a PR; it needs network, so run it when you mean to open one.
4. Draft PR. Write the title, the problem, the change, behavior change, and tests run. Search for duplicates first.
5. No product rewrite. The PR changes V. It never moves Hedronite code into V.

§VI. Lab: rehearse steps 2 and 3

The lab ran on the lab Mac with the prebuilt binary at ~/src/vlang-duha6/v/v (V 0.5.2 7647ce1) by absolute path, in scratch ~/src/vlang-duha9-lab/. The script exported V_C_ERROR_BUG_REPORT_DISABLED=1 as its first command and capped each command at 60 seconds. Nothing was built from source.

It made a tiny module clamp with one function and one test, put it in a local git repo, committed it unformatted, and branched to fix_clamp_fmt.

Two findings. First, fmt -verify is a real gate: it exits non-zero on an unformatted file, so step 2 can sit in a script. Second, the test step ran in under half a second for a one-file module, so running the nearest test costs nothing; the slow part is test-all. No fork, no remote, no push. Step 1 and step 4 stay on paper.

Bug-report note. V 0.5.2 auto-uploads C-error reports (up to 40 source lines each side, C context, build options) to bugs.vlang.io. This is documented in v help build-c, not in docs.md. Disable it with export V_C_ERROR_BUG_REPORT_DISABLED=1. No C error occurred in this lab, so nothing was sent.

§VII. Common mistakes

1. Treating a claim as a fact. "(wip)" is in the README line itself. Quote it with the marker.
2. Letting the learn seat vote on the adopt seat. A good week of PR practice is not evidence for production use.
3. Skipping the ladder. Opening a feature PR before reproducing a few issues goes against the order CONTRIBUTING.md sets.
4. Pushing to origin. CONTRIBUTING.md says push only to your own fork.
5. Running V labs without the opt-out. The first C error sends source to a public server.

§VIII. Contributor-path takeaway

Fork, fmt, test, draft. Learn V on its own terms, give it small correct PRs, and keep it out of every Hedronite product until the facts change. Next V step, if Evan wants one: pick a Starting task 5 issue, reproduce it on the lab Mac, and write the comment text.

---