Holistic vs core, V vs Go

[kfsone]

TL;DR1: consider serving a holistic "bells and whistles" vlang which has "vlang-core" almost as a submodule.
TL;DR2: consider replacing "how to install..." with links to v sub-commands/vsh steps,

Batteries included is the first thing I think of when I think of Go. All the tutorials, guides, demos work without any 3rd party modules/packages, and when you finally do need dependencies, there's a go ... encapsulated way to get it done.

When you're reading a language's documentation and it resorts to native command line steps, that's a pungent odor of looming "worked on my machine", it would give many devops engineers pause.

I started out my V experience with the "simple blog tutorial". 10+ years of reading the "you need sqlite" warning on python/other languages has conditioned me to skip, oops on me.

That means, though, that successfully completing the tutorial is predicated on the user recognizing that the 1-line call out to making sure you have sqlite is a manifestation of the author being a little ashamed and not wanting to just write "at this early stage in development, you do infact have to install sqlite. here's exactly what you need to do".

Bear with me on this: it means that someone went thru the following process.

1. Identify problem,
2. Determine resources to solve problem,
3. Produce a set of machine-readable shell commands to retrieve and emplace the resources,
4. [hopefully] tested the above was correct,
5. Identified a location to store the above knowledge,
6. Chose to translate those machine-readable instructions into human-readable natural language and find a location to store those that requires a user to search for them based on a c-compiler generated orthogonal-reading error message (that is: it doesn't say "3rd party sqlite package missing")

Suggestion A If you're going to write instructions, make as many of them machine readable as possible.

Suggestion B Use vsh or add sub-commands to v.

Suggestion C Consider a holistic bootstrap option: either swap the current vlang repository for a batteries-included, bells-and-whistles with everything needed for 99% of the core features, tutorials etc, and make the core vlang repository a sub-repository/module;

Suggestion D Alternately: Consider having two new make targets: "nobootstrap" equivalent to current default, "bootstrap" which goes and fetches everything you need

The big turn off for the project I was hoping to introduce to v instead of go is that cross-compiling definitely doesn't just work, and it seems largely to be a side-effect of this?

Win|PS> v -os linux .
Downloading files for Linux cross compilation (~22MB) ...
Cloning into 'C:\Users\oliver\.vmodules\linuxroot'...
remote: Enumerating objects: 1267, done.
remote: Counting objects: 100% (1267/1267), done.
remote: Compressing objects: 100% (821/821), done.
remote: Total 1267 (delta 362), reused 1228 (delta 328), pack-reused 0
Receiving objects: 100% (1267/1267), 39.16 MiB | 7.57 MiB/s, done.
Resolving deltas: 100% (362/362), done.
Updating files: 100% (1439/1439), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'include/X11/bitmaps/Stipple'
  'include/X11/bitmaps/stipple'
Cross compilation for Linux failed (first step, cc). Make sure you have clang installed.

and

Win|PS> v -os macos .
Note: V can only cross compile to windows and linux for now by default.
It will use `cc` as a cross compiler for now, although that will probably fail.
Set `VCROSS_COMPILER_NAME` to the name of your cross compiler, for your target OS: MacOS .
No input .v files

A possible solution for windows is ensuring that the "Visual Studio Build Tools" are installed providing the user with clang.
https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-build-tools?view=vs-2022#desktop-development-with-c which you could install/manage with either (win10+ built-in) winget, (user-install required) choco, or (ships with visual studio etc) nuget; other package managers exist but those are the 3 I see most commonly.

Is it just the availability of clang that is currently blocking -os macos?