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

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:
> > 
> > On Tue, 16 Sep 2025 13:59:53 +0300
> > Anthony Pankov <anthony.pankov@yahoo.com> wrote:
> >   
> >> Just for note.
> >> 
> >> XLibre developer(s) is trying to (automatically) convert X server sources
> >> to V language.
> >> 
> >> (below opinion is not related to XLibre people)
> >> 
> >> V language is a transpiler. May be it has a good ratio of cost of
> >> maintaining in the src codebase to increasing src audience/contributors. 
> >> 
> >> V is aimed to be a "simple language for building maintainable programs".
> >> This claim make it theoretically suitable for developing none performance
> >> critical programs in an operating system base.
> >> 
> >> 
> >> As for XLibre I think they would like to express (part of) a long lived
> >> and rarely touched C-codebase in a more maintainable and understandable
> >> way. Which allow them to touch a code with a more confidence when it is a
> >> necessarity for.  
> > 
> > While good compilation speed and small size is a plus, in my opinion, a new
> > language in base system must offer simplicity in writing scripts which
> > offer scripting languages. A quick look at V shows it has e.g. immutable
> > strings so it is not very free from boilerplates. After Perl axed out, we
> > have only awkward /bin/sh as alternative which often lacks features, and
> > going down (to low-level) is bad option, we need to go up.
> > 
> > May be I'm missing something and V is more friendly and high-level?  
> 
> You can write scripts in V (will be compiled on the fly and run). But it
> is a compiled language, better to use in place of C for new code (& so
> competes with rust, zig, etc.).

The borderline meant here is not ability to run on the fly (though it's very
desirable, but waht shipped in FreeBSD base could be precompiled) but a
higher-level nature of scripting languages, usually including dynamic typing.

> V is higher level than C. See vlang.io or its wikipedia page. It is much
> like Go (but GC is optional). It does allow potentially unsafe behavior
> provided you wrap it in "unsafe{ .. }".

I've seen it, and that's why the question - language like Go will not buy us
much. In contrast to Rust, may be, but language like Go is not a big
improvement over C. Especially given that V follows BDSM-style "there is only
one way to do it".

> But it is still at version 0.4.12 & there will likely be breaking changes
> until it reaches 1.0.
> 
> > 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
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.
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?

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.

-- 
WBR, @nuclight