I have used both Go (extensively) and V (not so much). Go's cross compilation, concurrency support, GC & stability are much better than V's. V compiles much much faster in spite of generating C (unless you use clang), plays better with C, its syntax choices seem better (default to const, less onerous error handling, sum types, option type, not relying on Capitalization for exporting etc.), optional GC (though far from perfect), etc. I can see writing an OS in V (but not in Go). I am in two minds about whether it should try to simulate concurrency like Go does (goroutines are coroutines, mapped to system threads only for blocking syscalls) as that might not be the right choice for kernel level code.
V hasn't had the resources or backing that Go continues getting. Most of its work is done by volunteers. AFAIK it hasn't had the benefit of the experience of multiple world class programmers like Go's designers. Good language design also involves leaving out features and that involves discussing or experimenting with such features. IMHO V can use more of that. But so far I like a lot of what I see in V.
The article author, Kris Tun, agrees you - "I like V a lot. The abstraction over the syntax is so nice that made me enjoy writing the syntax as a whole. It makes me wish that Go could do more with what they have, but you and I know that Go would never."
What also comes across is his open-mindedness and enthusiasm for the language. There have been many Golang developers, including those who created and joined the V (Vlang) project, that wanted particular features. After being able to get what they wanted, they are happy about it.
AFAIK this is far more common in muslims but not in hindus, jains etc. While growing up I had heard/read that as per the Vedas you can not marry someone with whom you have a common ancestor within 7 generations. [My scientifically minded atheist parents agreed with the idea.] Of course, in practice this isn't always followed but in any arranged marriage such proscriptions would presumably be checked.
I used the rand editor in early 80s & loved its “infinite” quarter plane model. Dave Yost enhanced it quite a bit and called it the Grand editor. But it was hard to maintain as it relied on K&R C. Eventually I gave up and went back to vi.
This was explained in the post. 1999 was when Intel released the Pentium 3 with SSE instructions, which caused the first major issue that had to overcome.
She was on a tourist visa. She should have gotten a J-1 visa who can do 20 hours/week part time work with some constraints. Some details about this visa: https://yfuusa.org/2024/05/16/j1-student-visa/
> The solution for C I proposed is backwards compatible, and does not make existing code slower.
Where can I read about it? The only way to make ptrs to array elements also safe that I can think of, is to replace them with triples: (base, element ptr, limit).
Thanks. I got interested in this topic as people are talking about writing OS kernel code in Rust but a) it only helps new code and b) very hard to justify rewriting millions of lines of C code in Rust (plus rewrites are never 100% faithful feature wise). If on the other hand if C can be made safer, may be through a stepwise process where the code is rewritten incrementally to pass through C->C0->C1->Cn compilers, each making incremental language changes, much more of code can be made safer. It will never be as good as Rust but I do think this space is worth exploring.
The production (clang backend) parallel build of V language takes about 3.2 seconds. All on an m1 mac. Even the go compiler seems slow in comparison.