forked from cadey/xesite
Return v post (#167)
* Revert "yaml" This reverts commit0c926583a9. * Revert "blog/vlang-update: tombstone post" This reverts commit78bcfcfd98. * edit down V post * Update vlang-update-2020-06-17.markdown * Update vlang-update-2020-06-17.markdown
This commit is contained in:
GitHub
parent
00273025e1
commit
766d8b6ae2
|
|
@ -1,9 +1,264 @@
|
||||||
---
|
---
|
||||||
title: "[removed]"
|
title: V Update - June 2020
|
||||||
date: 2020-06-17
|
date: 2020-06-17
|
||||||
|
series: v
|
||||||
---
|
---
|
||||||
|
|
||||||
This post has been removed. I will learn from my mistakes that lead to this post
|
# V Update - June 2020
|
||||||
being authored and published.
|
|
||||||
|
|
||||||
I was in a bad mental state when I wrote this and it really shows.
|
Every so often I like to check in on the [V Programming Language][vlang]. It's been
|
||||||
|
about six months since [my last post](https://christine.website/blog/v-vvork-in-progress-2020-01-03),
|
||||||
|
so I thought I'd take another look at it and see what progress has been done in six
|
||||||
|
months.
|
||||||
|
|
||||||
|
[vlang]: https://vlang.io
|
||||||
|
|
||||||
|
Last time I checked, V 0.2 was slated for release in December 2019. It is currently
|
||||||
|
June 2020, and the latest release (at time of writing) is [0.1.27][vrelease0127].
|
||||||
|
|
||||||
|
## Feature Updates
|
||||||
|
|
||||||
|
Interestingly, the V author seems to have walked back one of their original
|
||||||
|
listed features of V and now has an [abstract syntax tree][ast] for representing the
|
||||||
|
grammar of the language. They still claim that functions are "pure" by default, but
|
||||||
|
allow functions to perform print statements while still being "pure". Printing data
|
||||||
|
to standard out is an impure side effect, but if you constrain the definition of
|
||||||
|
"side effects" to only include mutability of memory, this could be fine. There
|
||||||
|
seems to be an issue about this on [the github tracker][vpure], but it was
|
||||||
|
closed.
|
||||||
|
|
||||||
|
[vrelease0127]: https://github.com/vlang/v/releases/tag/0.1.27
|
||||||
|
[ast]: https://github.com/vlang/v/commit/093a025ebfe4f0957d5d69ad4ddcdc905a6d7b81#diff-5adb689a65970037f7f0ced3d4b9e800
|
||||||
|
[vpure]: https://github.com/vlang/v/issues/4930
|
||||||
|
|
||||||
|
The next stable release 0.2 seems to be planned for June 2020 (according to the readme);
|
||||||
|
and according to the todo list in the repo, memory management seems to be one of the
|
||||||
|
things that will be finished. V is also apparently in alpha, but will also apparently
|
||||||
|
jump from alpha directly to stable? Given the track record of constantly missed
|
||||||
|
release windows, I am not very confident that V 0.2 will be released on time.
|
||||||
|
|
||||||
|
Tools like this need to be ready when they are ready. Trying to rush things is a
|
||||||
|
very unproductive thing to do and can result in more net harm than good.
|
||||||
|
|
||||||
|
## Build
|
||||||
|
|
||||||
|
Testing V is a bit more difficult for me now as its build process is incompatible
|
||||||
|
with my Linux tower's [NixOS](https://nixos.org/nixos) install (I tend to try and
|
||||||
|
package all the programs I use for testing this stuff so it is easier to reproduce
|
||||||
|
my environment on other machines). The V scripts also do not work on my NixOS tower
|
||||||
|
because it doesn't have a `/usr/local/bin`. The correct way to make a shell script
|
||||||
|
cross-platform is to use the following header:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
#!/usr/bin/env v
|
||||||
|
```
|
||||||
|
|
||||||
|
This makes the `env` program search for the V binary in your `$PATH`, and will
|
||||||
|
function correctly on all platforms (this may not work on environments like [Termux](https://termux.com/)
|
||||||
|
due to limitations of how Android works, but it will solve 99% of cases. I am unsure
|
||||||
|
how to make a shell script that will function properly across Android and non-Android
|
||||||
|
environments).
|
||||||
|
|
||||||
|
The Makefile in the V source tree seems to do
|
||||||
|
network calls, specifically a `git clone`. Remember that this is on the front page
|
||||||
|
of the website:
|
||||||
|
|
||||||
|
> V can be bootstrapped in under a second by compiling its code translated to C with a simple
|
||||||
|
>
|
||||||
|
> `cc v.c`
|
||||||
|
>
|
||||||
|
> No libraries or dependencies needed.
|
||||||
|
|
||||||
|
Git is a dependency, which means perl is a dependency, which means a shell is a
|
||||||
|
dependency, which means glibc is a dependency, which means that a lot of other
|
||||||
|
things (including posix threads) are also dependencies. Pedantically, you could even
|
||||||
|
go as far as saying that you could count the Linux kernel, the processor being used
|
||||||
|
and the like as dependencies, but that's a bit out of scope for this.
|
||||||
|
|
||||||
|
I claim that the V compiler has dependencies because it requires other libraries
|
||||||
|
or programs in order to function. For an example, see the output of `ldd` (a
|
||||||
|
program that lists the dynamically linked dependencies of other programs) on the
|
||||||
|
V compiler and a hello world program:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ ldd ./v
|
||||||
|
linux-vdso.so.1 (0x00007fff2d044000)
|
||||||
|
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fb3e4c000)
|
||||||
|
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fb3a5b000)
|
||||||
|
/lib64/ld-linux-x86-64.so.2 (0x00007f2fb4345000)
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
$ ldd ./hello
|
||||||
|
linux-vdso.so.1 (0x00007ffdfdff2000)
|
||||||
|
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fed25771000)
|
||||||
|
/lib64/ld-linux-x86-64.so.2 (0x00007fed25d88000)
|
||||||
|
```
|
||||||
|
|
||||||
|
If these binaries were really as dependency-free as the V website claims, the
|
||||||
|
output of `ldd` would look something like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ ldd $HOME/bin/dhall
|
||||||
|
not a dynamic executable
|
||||||
|
```
|
||||||
|
|
||||||
|
The V compiler claims to have support for generating machine code directly, but
|
||||||
|
in my testing I was unable to figure out how to set the compiler into this mode.
|
||||||
|
|
||||||
|
## Memory Management
|
||||||
|
|
||||||
|
> V doesn't use garbage collection or reference counting. The compiler cleans
|
||||||
|
> everything up during compilation. If your V program compiles, it's guaranteed
|
||||||
|
> that it's going to be leak free.
|
||||||
|
|
||||||
|
Accordingly, the documentation still claims that memory management is both a work in
|
||||||
|
progress and has (or will have, it's not clear which is accurate from the
|
||||||
|
documentation alone) perfect accuracy for cleaning up things at compile time.
|
||||||
|
Every one of these posts I have run a benchmark against the V compiler, I like to
|
||||||
|
call it the "how much ram do you leak compiling hello world" test. Last it leaked
|
||||||
|
`4,600,383` bytes (or about 4.6 megabytes) and before that it leaked `3,861,785`
|
||||||
|
bytes (or about 3.9 megabytes). This time:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ valgrind ./v hello.v
|
||||||
|
==5413== Memcheck, a memory error detector
|
||||||
|
==5413== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
|
||||||
|
==5413== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
|
||||||
|
==5413== Command: ./v hello.v
|
||||||
|
==5413==
|
||||||
|
==5413==
|
||||||
|
==5413== HEAP SUMMARY:
|
||||||
|
==5413== in use at exit: 7,232,779 bytes in 163,690 blocks
|
||||||
|
==5413== total heap usage: 182,696 allocs, 19,006 frees, 11,309,504 bytes allocated
|
||||||
|
==5413==
|
||||||
|
==5413== LEAK SUMMARY:
|
||||||
|
==5413== definitely lost: 2,673,351 bytes in 85,739 blocks
|
||||||
|
==5413== indirectly lost: 4,265,809 bytes in 77,711 blocks
|
||||||
|
==5413== possibly lost: 256,000 bytes in 1 blocks
|
||||||
|
==5413== still reachable: 37,619 bytes in 239 blocks
|
||||||
|
==5413== suppressed: 0 bytes in 0 blocks
|
||||||
|
==5413== Rerun with --leak-check=full to see details of leaked memory
|
||||||
|
==5413==
|
||||||
|
==5413== For counts of detected and suppressed errors, rerun with: -v
|
||||||
|
==5413== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
|
||||||
|
```
|
||||||
|
|
||||||
|
It seems that the memory managment really is a work in progress. This increase in
|
||||||
|
leakage means that the compiler building itself now creates `7,232,779` bytes of
|
||||||
|
leaked ram (which still is amusingly its install size in memory, when including
|
||||||
|
git deltas, temporary files and a worktree copy of V).
|
||||||
|
|
||||||
|
## Doom
|
||||||
|
|
||||||
|
The [Doom](https://github.com/vlang/doom) translation project still has one file
|
||||||
|
translated (and apparently it breaks sound effects but not music). I have been
|
||||||
|
looking forward to the full release of this as it will show a lot about how
|
||||||
|
readable the output of V's C to V translation feature is.
|
||||||
|
|
||||||
|
## 1.2 Million Lines of Code
|
||||||
|
|
||||||
|
Let's re-run the artificial as heck 1.2 million lines of code benchmark from the
|
||||||
|
last post:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ bash -c 'time ~/code/v/v main.v'
|
||||||
|
|
||||||
|
real 7m54.847s
|
||||||
|
user 7m32.860s
|
||||||
|
sys 0m14.212s
|
||||||
|
```
|
||||||
|
|
||||||
|
Compared to the last time this benchmark was run, this took 2 minutes less (last
|
||||||
|
time it took about 10 minutes). This is actually a major improvement, and means
|
||||||
|
that V's claims of speed are that much closer to reality at least on my test
|
||||||
|
hardware.
|
||||||
|
|
||||||
|
## Concurrency
|
||||||
|
|
||||||
|
A common problem that shows up when writing multi-threaded code are
|
||||||
|
[race conditions][races]. Effectively, race conditions are when two bits of code try
|
||||||
|
to do the same thing at the same time on the same block of memory. This leads to
|
||||||
|
undefined behavior, which is bad because it can corrupt or crash programs.
|
||||||
|
|
||||||
|
[races]: https://en.wikipedia.org/wiki/Race_condition
|
||||||
|
|
||||||
|
As an example, consider this program `raceanint.v`:
|
||||||
|
|
||||||
|
```
|
||||||
|
fn main() {
|
||||||
|
foo := [ 1 ]
|
||||||
|
go add(mut foo)
|
||||||
|
go add(mut foo)
|
||||||
|
|
||||||
|
for {}
|
||||||
|
}
|
||||||
|
|
||||||
|
fn add(mut foo []int) {
|
||||||
|
for {
|
||||||
|
foo[0] = foo[0] + 1
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
In theory, this should have two threads infinitely trying to increment `foo[0]`,
|
||||||
|
which will eventually result in `foo[0]` getting corrupted by two threads trying to
|
||||||
|
do the same thing at the same time (given the tight loops invovled). This leads
|
||||||
|
to undefined behavior, which can be catastrophic in production facing applications.
|
||||||
|
|
||||||
|
However, I can't get this to build:
|
||||||
|
|
||||||
|
```
|
||||||
|
==================
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c: In function ‘add_thread_wrapper’:
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c:1209:6: error: incompatible type for argument 1 of ‘add’
|
||||||
|
add(arg->arg1);
|
||||||
|
^~~
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c:1198:13: note: expected ‘array_int * {aka struct array *}’ but argument is of type ‘array_int {aka struct array}’
|
||||||
|
static void add(array_int* foo);
|
||||||
|
^~~
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c: In function ‘strconv__v_sprintf’:
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c:3611:7: warning: variable ‘th_separator’ set but not used [-Wunused-but-set-variable]
|
||||||
|
bool th_separator = false;
|
||||||
|
^~~~~~~~~~~~
|
||||||
|
/home/cadey/.cache/v/raceanint.tmp.c: In function ‘print_backtrace_skipping_top_frames_linux’:
|
||||||
|
...
|
||||||
|
==================
|
||||||
|
(Use `v -cg` to print the entire error message)
|
||||||
|
|
||||||
|
builder error:
|
||||||
|
==================
|
||||||
|
C error. This should never happen.
|
||||||
|
|
||||||
|
If you were not working with C interop, please raise an issue on GitHub:
|
||||||
|
|
||||||
|
https://github.com/vlang/v/issues/new/choose
|
||||||
|
```
|
||||||
|
|
||||||
|
Like I said before, I also cannot file new issues about this. So if you are willing
|
||||||
|
to help me out, please open an issue about this.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
EDIT(Xe): 2020 M06 23
|
||||||
|
|
||||||
|
I do not plan to make any future update posts about the V programming language
|
||||||
|
in the future. The V community is something I would really rather not be
|
||||||
|
associated with. This is an edited-down version of the post that was released
|
||||||
|
last week (2020 M06 17).
|
||||||
|
|
||||||
|
As of the time of writing this note to the end of this post and as far as I am
|
||||||
|
aware, I am banned from being able to contribute to the V language in any form.
|
||||||
|
I am therefore forced to consider that the V project will respond to criticism
|
||||||
|
of their language with bans. This subjective view of reality may not be accurate
|
||||||
|
to what others see.
|
||||||
|
|
||||||
|
I would like to see this situation result in a net improvement for everyone
|
||||||
|
involved. V is an interesting take on a stagnant field of computer science, but
|
||||||
|
I cannot continue to comment on this language or give it any of the signal boost
|
||||||
|
I have given it with this series of posts.
|
||||||
|
|
||||||
|
Thank you for reading. I will continue with my normal posts in the next few
|
||||||
|
days.
|
||||||
|
|
||||||
|
Be well.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue