Re: candidate of add. language in src (not rust)

On Sep 20, 2025, at 12:56 PM, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
> 
> On Sat, 20 Sep 2025 11:37:44 -0700
> Bakul Shah <bakul@iitbombay.org> wrote:
> 
>> On Sep 20, 2025, at 9:00 AM, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
>>> 
>> 
>>> it has e.g. immutable strings so it is not very free from boilerplates.  
>> 
>> Not sure why you think so.
> 
> Consider not even Shell, but e.g. sed, awk or Perl. It's very easy in them to
> write replacing a part of string, like s/foo/bar/ or appending/prepending
> something to string. It's very common is scripts (and Makefiles, which also
> could be considered high-level scripting language) to write such, but tedious

Immutable strings simply means you can't index and replace a char
but you can use regex or append/prepend and assign to the same var.
For ex, x = "pre-"+x+"-post". Its string library is similar to Go's.
Much less error prone or fiddly than C's.

> to do in languages like C. In a quick scroll via V's marketing docs, examples
> had at least to write "mut" before each variable - which is boilerplate, too.

V's default is the opposite of C to reduce foot-shooting. So you need
mut in V for mutable where as in C you need const for immutable objects.

> What I'm speaking about is expresiveness, that is, ability to write less
> characters to do the same thing, thus comfort of programmer - for example, you
> will need to write much less code for the same task in Perl or Python than in
> C (awk/shell similar but have less features and harder to maintain) - then,
> what about V in such tasks?

I would think similar to Python or Go but that is just a guess.

> As an example, /usr/sbin/adduser could be taken: it was a Perl script which
> was then replaced by Shell script in commit 7cdfce092a3, from about ~1500
> lines file (yes, shell version is smaller but Shell is harder to maintain -
> everyoine dealt with freebsd-update(8) internals knows!). How many lines would
> take it, if implemented in V ? Note that exactly Shell was chosen for such
> rewriting in 2002, not C - for exactly reasons I'm speaking above. And I've
> omitted all those "safety" reasons - because it is what you already have by
> default out-of-the-box in scripting languages, but have to put efforts to
> achieve it - in C or Rust.

Here C was perhaps found to be too low level hence shell. For this sort of
cases V would make a good candidate, as string manipulation is easier in V
than C. But it won't replace a proper scripting language.

Dynamic languages come with their own tradeoffs. The problem is finding a
sweet spot between simplicity & convenience, between performance and less
foot shooting, between conciseness and readability. And that sweet spot is
different for different tasks.

Note that I am not advocating for inclusion of V. When its language defn
reaches version 1.0 (and will not be broken byr any further versions), it
can be evaluated.