V Update - June 2020

39

icefox 3 years ago | link

It’s an interesting update, but I’d be happier simply forgetting it existed along with everyone else.

11

dmytrish edited 3 years ago | link

My fear about this is that it can actually capture some programming domain and we’ll forget about this just to wake up with another PHP on our hands.

This is not a baseless fear: both V’s author and community are relentlessly and aggressively self-promotional, they push a narrative of a perfect language non-stop (just look at the comments below), even though its incoherence and empty promises have been easily demonstrated many times.

A bit of negative hype might be justified.
1. 6
  icefox edited 3 years ago | link
  Potentially valid, but it seems like the more effective way would be to make better tools and promote them better. I still am not yet aware of a good plug-and-play system that can do some of the things that PHP can quite as simply.
  
  Case study: I made the Rust crate ggez because the main community game engine at the time was piston. piston was so damn bad that I wrote an entire game framework to avoid it, initially basically as an attempt to kill piston, and I’m pretty pleased at how it’s worked out. Could be better, but I don’t think I’m being too self-congratulating myself in saying that ggez is, if not the #1, then the #2 2D pure Rust game lib out there. I’d put a decent bet on it having more actual games and game experiments written using it than piston does. There are at least a couple Rust gamedev channels out there where the default answer to newbies saying “help I’m having trouble with piston” is people other than me saying “piston isn’t very good, why not try ggez?”… and these conversations invariably end with said newbie saying “wow, ggez is way nicer, thanks!”
  
  Now don’t get me wrong, I used to really hate piston. I felt it was a turd fragment stuck to the toilet bowl of the universe and I acted accordingly. But honestly, that never got me anywhere good and I’m personally happier taking a step back from worrying about it. So, negative hype has its place, but is only one part of a tool set. If you do it well and objectively, as this post does, then it serves as a useful reference point for follow-up conversations; if someone asks “well why DO you hate piston” and isn’t satisfied with a basic answer I aim them at my attempt at objective assessment. But it is only one part of the conversation, and it’s not the first part to aim people at.
  
  I’m hardly an expert on this, but so far these are my guidelines for gently smothering crap systems with better ones:
  
  Be the example you want. Make the alternative system better in every way. It’s useless to have superior code if your docs are crap, it’s useless to have superior docs if nobody can find them, it’s useless to have a well-organized project that nobody knows about.
  
  Market gently. Make announcements of major events in appropriate public places like reddit or mailing lists, but don’t try to overwhelm the hype of others. Just say “hey, we’re still here, doing cool stuff, here’s examples”. You don’t need to say “we’re better than X for these reasons”, just let your work speak for itself. Your stuff is inevitably cooler than your competition’s, and the people who matter will notice that.
  
  Never, ever, ever badmouth the competition. Never say “X is crap” or “Y is stupid”, even if it’s true. This just makes you look biased. People remember who you are, if they’re interested in this topic, and developing a reputation for having a personal hate-on for a system is not useful.
  
  Never compete with good systems. There are plenty of other 2D game libs out there for Rust, with various upsides and downsides. I’d happily recommend ggez over quicksilver for the things its better at, but quicksilver does useful things that ggez doesn’t as well. So I’m now buddies with the creators of most of these systems, we hang out and talk gamedev, and it’s usually useful for everyone.
  
  If you want to market one system to a user over another one, always do it invitingly. Never say “you should use X, Y is crap”, you say “why did you choose X over Y?” Often the answer is “X was the first thing I picked up” or “I have a use case that Y doesn’t solve”. If someone still chooses X over better alternatives, you shrug and walk away because they don’t know what they’re doing and their project is probably doomed to failure anyway.
  
  Target your effort strategically. I just checked crates.io, and piston has 160k downloads while ggez has 40k. Irksome, but why is this? Now, it looks like the main user of the piston crate is piston_window, which is used mainly by the plotters crate, which is a (novel and rather nice looking) plotting lib. plotters‘s main reverse dependency is criterion, which is an awesome benchmarking crate – so that makes total sense. criterion is awesome and well-known, it uses plotters, and so piston gets tons of downloads. But plotters isn’t a game engine, it presumably doesn’t really care about piston, it just wants a handy window it can draw on without too much fuss. ggez is not a good option for that, but it’s a perfectly reasonable thing to want to do. So, if I wanted to cut into piston‘s mindshare, the best way isn’t to update my objective assessment rant and point out all its piston‘s flaws, but rather to submit a PR to plotters saying “here’s a new window backend using something else, it has advantages A B and C over the current model”. If I can’t do that… then the problem isn’t that piston exists, the problem is that it’s the best solution for a valid use case.
  
  Anyone with suggestions and tips on doing this better, please let me know.
  
  You’re playing the long game here. But so far I’ve seen this sort of approach work pretty well, albeit on one data point in my fairly small and niche domain. You don’t have to murder the bad system, you just have to arrange it so that the better system is set up for inevitable success and then let things take their course. Which is hard; the world is full of WorseIsBetter systems that exist mainly because of external factors that set up the bad system for inevitable success. But young, open source projects that fill a specific need that isn’t being otherwise filled is probably the easiest context to do this in. As an analogy, Go didn’t succeed (only) because it was backed by Google, and node.js didn’t succeed (only) because it was written in Javascript. Both succeeded because, in 2010, the main alternatives for writing server backends were Python/Ruby, Java/C#, or C/C++. Go and Node filled a niche for high-performance, low-friction systems of a particular kind, that was not being served well by existing solutions.
2. -6
  
  elimisteve 3 years ago | link
  
  A bit of negative hype might be justified.
  
  Misrepresenting the project and its impressive progress is not an appropriate way to do that! See my main comment: https://lobste.rs/s/nfjifq/v_update_june_2020#c_vuofat

33

friendlysock edited 3 years ago | link

This is starting to look like bullying. I think the post is fine, but posting it here to point and gawk isn’t. :(

25

skelly 3 years ago | link

If someone makes bold claims about a project, then there’s nothing wrong with pointing out when those claims aren’t accurate.
1. 36
  
  friendlysock 3 years ago | link
  
  If we had a post for every software project that was still shit in spite of bold claims, the frontpage would be worthless.
  1. 13
    
    timetoplatypus 3 years ago | link
    
    It’s fair to say we don’t need a post for every piece of software that isn’t living up to its claims, but that doesn’t make this bullying.
  2. 17
    hwayne 3 years ago | link
    
    I think there are two differences here:
    
    @cadey wrote it but didn’t post it. I’m assuming @calvin shared it because he thought it was genuinely interesting content, not to bully V.
    
    It’s not just that V is still shit in spite of bold claims, it’s that V is still shit in spite of bold claims and incredibly toxic behavior by its community. The interplay between all three- toxicity, grandiosity, vaporware- makes this analysis especially interesting to me.
    1. -8
      
      elimisteve 3 years ago | link
      
      What toxicity are you talking about?
      
      If V is vaporware then how are so many of us using it for our projects? https://github.com/vlang/v
      
      Here’s a cool one: a first-person shooter game bot https://github.com/EasyHax/Vack
      1. 16
        
        hwayne 3 years ago | link
        
        What toxicity are you talking about?
        
        You, in this thread, right now.
        
        This is the only time I’m going to reply to you. And I only replied because nobody else has explicitly called out your hostility.
        
        -4
        
        elimisteve 3 years ago | link
        
        Defending V from misleading attacks – so misleading that the author has just retracted her original post – is not exactly a defensible definition of “toxic”.
        
        I don’t like seeing slander against important projects I care about. Surely you can understand!
        
        13
        
        Lulu 3 years ago | link
        
        All I can see here is that the V community lives up to its infamy by bullying someone into taking down a critical piece on it.
        
        16
        
        cadey 3 years ago | link
        
        I retracted the post because of people like you. It wasn’t just you, but I just wanted an end to it.
        
        -5
        
        elimisteve edited 3 years ago | link
        
        If your post would have been factual then I wouldn’t have criticized it…
        
        I hope you are in a better headspace for your future posts. I’m sure many of us would love to read more articles about WasmCloud, which is honestly one of the coolest projects I’ve ever heard of; would solve many important problems at once, and do so without reinventing the wheel.
        
        (Dear readers: FWIW I didn’t ask for the post to be taken down. I was arguing against its content.)
2. 3
  
  soc 3 years ago | link
  
  Did I miss some drama about this project?
  1. 3
    
    agent281 3 years ago | link
    
    Yes.
3. -3
  
  elimisteve 3 years ago | link
  
  Which claims aren’t accurate, specifically?
  1. 9
    
    spc476 3 years ago | link
    
    As far as I can tell, compiling 1.2 million lines of code in a second (second bullet point). I would also like to see some citations backing up the safety guarantees with respect to C to V translation. C has way too many gotchas for a bold claim like that. Also, the safety guarantee with the C and Javascript backends.
    1. -1
      
      volt_dev edited 3 years ago | link
      
      You can download the project, generate 1 million lines of code using tools/gen_1mil.v and build it in 1 second with v -x64 x.v
      
      “ safety guarantee with the C backend” makes no sense, because you write the code in V, not in C. V won’t allow you globals, or shadowing etc. C can be thought of as an assembly language.
      1. 7
        
        yorickpeterse 3 years ago | link
        
        If only this benchmark actually worked. First I compiled the generator using:
        
        ./v -prod cmd/tools/gen1m.v
        
        This already takes 1.3 seconds. I then ran the resulting binary as follows:
        
        ./cmd/tools/gen1m > big.v
        
        The size of the resulting file is 7.5 megabytes. I then tried to compile it as follows:
        
        ./v -prod big.v
        
        This takes 2.29 seconds, produces 7 errors, and no output binary. This is the same when using the -64 option, and also when leaving out the -prod option.
        
        Even a simple hello world takes longer than a second in production mode:
        
        v $ cat hello.v fn main() { println("Hello world") } v $ time ./v -prod hello.v ________________________________________________________ Executed in 1,44 secs fish external usr time 1372,26 millis 350,00 micros 1371,91 millis sys time 64,93 millis 28,00 micros 64,90 millis
        
        In debug mode it already takes 600 milliseconds:
        
        v $ time ./v hello.v ________________________________________________________ Executed in 666,51 millis fish external usr time 613,46 millis 307,00 micros 613,15 millis sys time 52,61 millis 26,00 micros 52,59 millis
        
        With -x64 a debug build takes about 2 milliseconds.
        
        Based on the above I find it hard to believe V would really be able to compile over a million lines of code in less than one second; even without optimisations enabled. I hope I am wrong here.
        
        The hardware used is as follows:
        
        CPU: AMD Ryzen 5 1600X
        
        RAM: 4x Kingston KHX2400C15D4/4G, a total of 16GB
        
        SSD: Samsung 860 EVO 250GB
13

proctrap 3 years ago | link

maybe, but as icefox said I also feel like christine is giving V too much PR with it
5

hyperpape edited 3 years ago | link

I agree that it’s unnecessary, though I can’t decide if it’s really bullying.

I’ve heard about V two times since the last post hit lobste.rs. One time I posted Christine’s observations, one time someone else did. I think the message is out there, and at this point, it’s really only noteworthy if something changes.
1. -5
  
  elimisteve 3 years ago | link
  
  What message is out there? That the misleading attacks on V continue?
5

andyc 3 years ago | link

Yeah there is some interesting technical content in the post, but the tone is offputting.
4

zem 3 years ago | link

I was amused to see it tagged “performance”, wonder if the pun was intentional on the submitter’s part.
7

zge 3 years ago | link

Abuse that gets a lot of “positive engagement” is deemed entertainment.

13

goggle 3 years ago | link

If you look at the history of the README, you see that they initially claimed that a stable V 1.0 is ready for December 2019. Then they decreased the stable version number to 0.2 and also claimed it will be available in December 2019. But it didn’t happened. Then they claimed it would be ready in January 2020, February 2020, Mars 2020, April 2020, and now June 2020. This is ridiculous!

Why do they even proclaim a release date? Every potential user is disappointed when they see that it got postponed for another month.

7

timetoplatypus 3 years ago | link

Are any of the examples in the V playground working for anyone? I get the following error for every single one:

You just found a bug. V can’t compile this program, but it should. Please create a GitHub issue.

1

elimisteve 3 years ago | link

There’s a new WASM-based playground that’s been around for about a month and that is now linked to on the V homepage!

Here you go: https://v-wasm.now.sh/
-1

elimisteve 3 years ago | link

I just reported this, thanks!

In the meantime, check out https://github.com/vlang/v/blob/master/doc/docs.md and https://vlang.io/compare .
1. 1
  
  inactive-user 3 years ago | link
  
  For which good reason software communities feel like blaming (downvoting) someone for reporting and fixing bugs?

4

HenriTuhola 3 years ago | link

Could you throw some sack on Lever? This is author’s request, you will be welcome to do that.

2

cadey 3 years ago | link

I can try!

3

ac edited 3 years ago | link

The author says hello is leaking memory, but valgrind is clearly saying 0 bytes were lost.

$ valgrind ./hello                                                                               
...                                                                      
==13258== LEAK SUMMARY:                                                                          
==13258==    definitely lost: 0 bytes in 0 blocks                                                
==13258==    indirectly lost: 0 bytes in 0 blocks                                                
==13258==      possibly lost: 0 bytes in 0 blocks                                                
==13258==    still reachable: 12,144 bytes in 14 blocks

2

elimisteve edited 3 years ago | link

As someone who is in V’s Discord every day being constantly blown away at the progress being made, I am shocked at the level of dishonesty that this strangely anti-V hit piece achieves.

In particular, the degree of cherry-picking (and often then still misrepresenting) a few facts in order to make V appear in the worst possible light is truly breathtaking.

She cites vlang.io saying

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.

then argues against it, preposterously, by saying in part,

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. …

Downloading a .c source file requires git? Does this person know what a “dependency” is? Should JavaScript developers include depending upon the laws of physics in package.json?

Amusingly, the documentation still claims that memory management is both a work in progress and has perfect accuracy for cleaning up things at compile time.

No, the documentation correctly says that memory management is a work in progress, and also that, once completed, will clean up after itself in much the way that Rust does.

An Honest Depiction of Progress

Here are the combined release notes from all of the V releases since December:

Release 0.1.23:

- [Direct x64 machine code generation](https://github.com/vlang/v/issues/2849). Hello world being built in 3 milliseconds.
- Bare metal support via the `-freestanding` flag, allowing to build programs without linking to libc.
- Prebuilt V packages for Linux, macOS, and Windows.
- `string.index()` now returns `?int` instead of `int/-1`.
- Lots of fixes in Generics.
- vweb framework for developing web applications is back.
- Vorum, the forum/blogging software written in V/vweb, can now be compiled and has been added to CI.
- REPL, `v up` have been split up into separate applications to keep the core V compiler small.
- V now enforces short enum syntax (`.green` instead of `Color.green`) when it's enough.
- V UI for macOS.
- Interfaces have been rewritten. `[]interface` support.
- `os.cp()` for copying files and directores.
- Additional compile-time flags: `$if clang, msvc, mingw, x32, x64, big_endian, little_endian {`.
- All C functions now have to be declared, all missing C functions have been defined.
- Global variables (only with the `--enable-globals` flag) for low level applications like kernels and drivers.
- Nothing can be cast to bool (previously code like `if bool(1) {` worked.
- `<<` and `>>` now work with all integer types.
- V detects Cygwin and shows an error. (V supports Windows natively)
- Improved type checking of some operators (`%, |, &` etc).
- Windows 7 support.
- `println(true)` now prints `true` instead of `1`.
- `os.exec()` now uses `CreateProcess` on Windows.
- fast.vlang.io website for monitoring the performance of V after every commit.
- On Windows Visual Studio is now used automatically if GCC is not installed.
- vfmt!
- Lots of cleaning up in the compiler code.
- Multi-level pointers in unsafe code (`****int`).
- MSVC backtrace.
- `$if os {` blocks are now skipped on a different OS.
- C string literals (`c'hello'`).
- AlpineLinux/musl fixes + added to CI.
- Inline assembly.
- Clipboard module (Windows, macOS, X).
- `foo()?` syntax for error propagation.
- Docs have been migrated from HTML to `doc/docs.md`.
- `eventbus` module.
- Haiku OS support.
- `malloc/free` on bare metal.
- `utf8` helper functions (`to_lower()`, `to_upper()`, etc).
- Optimization of `for c in str {`.
- `string/array.left/right/slice/substr` were removed (`[a..b]` slicing syntax should be used instead).

Release 0.1.24:

- A new parser/generator built on top of an AST that simplifies code greatly and allows to implement new
  backends much faster.
- Sum types (`type Expr = IfExpr | MatchExpr | IntegerLiteral`).
- B-tree map (sped up the V compiler by ~10%).
- `v fmt -w`.
- The entire code base has been formatted with vfmt.
- Generic structs.
- SDL module.
- Arrays of pointers.
- os: `is_link()`, `is_dir()`, `exists()`.
- Ranging through fixed size arrays.
- Lots of fixes in ORM and vweb.
- The first tutorial: [building a simple web application with vweb](https://github.com/vlang/v/blob/master/tutorials/building-a-simple-web-blog-with-vweb.md).
- Match expressions now must be exhaustive.
- freestanding: `malloc()`/`free()`.
- `++` is now required instead of `+= 1` for consistency.
- Interpolated strings now allow function calls: `println('val = $get_val()')`.
- `string.replace_each([])` for an efficient replacement of multiple values.
- More utf8 helper functions.
- `-prealloc` option for block allocations.
- `type` aliases.
- Running `v` with an unknown command will result in an error.
- `atof` implementation in pure V.
- Enums can now have negative values.
- New `filepath` module.
- `math.factorial`.
- `ftp` module.
- New syntax for casting: `val as Type`.
- Fewer libc functions used (soon V will have no dependency on libc).

Release 0.1.27:

- `vfmt` has been re-written from scratch using the new AST parser. It's much faster, cleaner, and can format
files with compilation errors.
- `strconv`, `sprintf`, and `printf` in native V, without any libc calls.
- Interfaces are now a lot more stable and have all expected features.
- Lots of x64 backend improvements: function calls, if expressions, for loops, local variables.
- `map()` and `filter()` methods can now be chained.
- New `[]int{cap:cap, len:len}` syntax for initializing array length and capacity.
- New `is` keyword for checking the type of sum types and interfaces.
- `as` can now be used to cast interfaces and sum types.
- Profiling with `-profile`. Prints a nice table with detailed information about every single function call:
number of calls, average time per call, total time per function.
- `import(xxx)` syntax has been removed in favor of `import xxx` for simplicity and greppability.
- Lots of fixes and improvements in the type checker.
- `time.StopWatch`
- `dl` module for dynamic loading.
- Automatic `str()` method generation for every single type, including all arrays and fixed size arrays.
- Short struct initialization syntax for imitating named function args: `foo(bar:0, baz:1)`.
- New operator `!in`.
- Performance improvements in critical parts of the builtin data structures (array, map).
- High order functions improvements (functions can now be returned etc).
- Anonymous functions that can be defined inside other functions.
- Built-in JSON module is back.
- Closures.
- Lots and lots of new tests added, including output tests that test error messages.
- Multiple errors are now printed, the compiler no longer stops after the first error.
- The new JS backend using the AST parser (almost complete).
- Variadic functions.
- `net.websocket` module (early stage).
- `vlib` is now memory leak free, lots of `autofree` improvements.
- Simplified and cleaned up `cmd/v`, `v.builder`.
- V UI was updated to work with the new backend.

After she COMPLETELY ignores the MASSIVE progress made – more than 3000 commits worth from a brilliant and fiercely dedicated team – and judges the current state of V based exclusively on misunderstandings, nitpicks, and on its memory management status after acknowledging that it’s not done yet and that the language is in an alpha state, she snarkily ends with:

Overall, V looks like it is making about as much progress as I had figured it would.

This is almost as bad as the quote she ended with in her previous post on V:

Don’t ever, ever try to lie to the Internet, because they will catch you. …

Honesty, Please!

If you want to know how well V is actually progressing, try it yourself, check out the Discord, look on GitHub, but whatever you do, do not focus on ignorant, dishonest, cherry-picked commentary from haters; that doesn’t serve anyone well, and is incredibly unfair to those who are pouring themselves into this important project.

The Brilliance of V

After my 11 years of programming, including 9.5 of programming in Go (which is the most similar language to V), I consider V to easily be the best-designed programming language that exists.

Yes, it’s learned a lot from Go and C, and maybe Lisp people prefer Lisp, but V successfully combines the simplicity of Go, the programmer ergonomics of Python, the speed C, and almost as many safety guarantees as Rust (once V has finished implementing these latter aspects, of course!).

What I thought would take the V team 5 years to implement has taken less than 1 year. Alex (V’s creator) thought it would take even less time, and now he’s being unfairly raked over the coals for setting extremely ambitious timelines while the same naysayers and bullies ignore everything that has been done.

V Resources

Website (including code examples): https://vlang.io/

GitHub: https://github.com/vlang/v

Wiki page explaining why C is used as in intermediate representation rather than LLVM (another brilliant move that allows V to build on the shoulders of giants and avoid reinventing the wheel in order to bootstrap a new language, but a move that is misunderstood and absurdly used to argue against V for doing things differently/better): https://github.com/vlang/v/wiki/On-the-benefits-of-using-C-as-a-language-backend

27

Corbin 3 years ago | link

I understand that you have strong feelings for your language of choice. Nonetheless, language designers are not entitled to a community, nor are they entitled to shelter from criticism. Indeed, one of the most important parts of programming language design is rejecting new languages based on showstoppingly-unacceptable design choices.

V does not offer any compelling design choices. Its advertised features can be sorted into libraries, compiler/toolchain offerings, and roughly the level of safety advertised in the 80s when memory-safety was still controversial. Just like Go, V has not learned many lessons, and refuses to offer programmers a more interesting way to express themselves. Even if V were literally Go but better, this would be sufficient to damn it.

I understand that you might not like it when people point out that the release dates keep slipping; I think it’s curious that you are willing to link to V’s wiki and source code, but not to bumping release dates.

As a language designer, I think that it is important to not advertise what you don’t yet have written. Monte has had one release, a developer preview, and we are intending to complete another iteration of bootstrapping before even considering another release. We know that almost every feature that typical end users will want is not yet written, and so we are not loudly advertising our offering as usable for everyday general-purpose programming, regardless of how much everyday general-purpose programming I or anybody else actually achieves with it.

I consider V to easily be the best-designed programming language that exists.

What’s your favorite ML? I have lately played with OCaml. There are entire universes of language designs which I suspect that you have yet to explore.
1. -4
  
  elimisteve 3 years ago | link
  
  Just like Go, V has not learned many lessons, and refuses to offer programmers a more interesting way to express themselves.
  
  FP diehards will never understand why Go has been so wildly successful – and V will be even more successful than Go.
  
  V is like Go but fixes all ~10 things wrong with it, providing a lot more flexibility due to its generic functions, generic structs, generic channels (still in the works), sum types, and TypeScript-style interfaces (also still partially in the works).
  
  Plus there’s the raw speed factor; V is translated to C before being compiled to machine code, cleverly piggybacking on decades of speed optimizations made by gcc/clang/tcc/etc.
  
  The simplicity of Go or Python + almost as much safety as Rust + almost exactly as much speed as C + a flexible type system + familiar syntax == a winning combination, I insist!
  1. 17
    
    c-cube 3 years ago | link
    
    The simplicity of Go or Python + almost as much safety as Rust + almost exactly as much speed as C + a flexible type system + familiar syntax == a winning combination, I insist!
    
    Except all of these are “some time in the future”, and widely incompatible with one another. There’s nothing to support any of these claims. What’s the design for “almost as much safety as rust” (without GC, of course)? The whole thing only just got an AST, and we’re supposed to believe it’s going to be revolutionary? There’s been a lot of grand promises with release dates being pushed back repeatedly, but nothing specific about how the promises will actually be achieved. Making a good language is hard, it takes years (if not decades), and you can’t just magically make something both simple, fast, safe, gc-free, etc. in a field where it’s known that some tradeoffs are inevitable.
    1. -3
      
      elimisteve 3 years ago | link
      
      Except all of these are “some time in the future”, and widely incompatible with one another.
      
      Nope, totally wrong. The simplicity is there, the speed is there, the flexible type system is there, and the familiar syntax is there. A safe subset of C is generated then compiled but not all the safety guarantees are implemented yet.
      
      There’s been a lot of grand promises with release dates being pushed back repeatedly
      
      V is the first software project in history to be finished later than originally intended ;-).
      
      The whole thing only just got an AST
      
      Completely false; V has always had an AST. The AST-related thing that’s new is representing the generated C code as an AST before outputting it.
      
      … you can’t just magically make something both simple, fast, safe, gc-free, etc. in a field where it’s known that some tradeoffs are inevitable.
      
      The big “a-ha” moment for me was this: I now realize that I had falsely assumed that just because prior languages took certain trade-offs that it was impossible to check all these boxes at once. But I was wrong.
      
      The only inherent tension between any of the things I listed is between simplicity and flexibility. But as I said in the comment you’re replying to,
      
      V is like Go but fixes all ~10 things wrong with it, providing a lot more flexibility due to its generic functions, generic structs, generic channels (still in the works), sum types, and TypeScript-style interfaces (also still partially in the works).
      
      The limiting factor is not some innate impossibility of making a language that is simple, fast, and safe. The limiting factor is creativity. But V has learned much from Go, Rust, Python, and other languages, and has unique insights of its own (like its error handling!).
      
      New things are, in fact, possible… and spelled out in detail on the website and in the docs, in this case. See for yourself: https://github.com/vlang/v/blob/master/doc/docs.md .
      1. 10
        
        sanxiyn 3 years ago | link
        
        the flexible type system is there
        
        hydraz below convincingly demonstrated that if function calls have generic types, type is not checked at all(!) in current V. How can you say type system is “there”? I guess it is “there” in terms of code generation, but if you are not checking types, saying type system is there is at best deceptive.
        
        -4
        
        elimisteve 3 years ago | link
        
        How can you say type system is “there”?
        
        …because there are types you can define and instantiate and do all the usual things that programming languages let you do with types…
        
        hydraz said,
        
        type errors for parameters in functions with a slapped on them are still silently ignored…
        
        Silently ignored? If you use a generic type in a way that’s invalid then the program won’t compile (yes, during the C -> machine code step).
        
        11
        
        hydraz edited 3 years ago | link
        
        I think you need to read my comments - and indeed, the compiler code that I linked - again. V has roughly no type system at all. The function, foo, that I wrote, isn’t generic!
        
        It does have a <T>, but there’s nothing to infer that T from (This should be a type error. It isn’t)
        
        It takes a string, but I can give it an int, and this should be an error, but the compiler has code specifically for silently ignoring these errors.
      2. 8
        
        c-cube 3 years ago | link
        
        spelled out in detail
        
        Let’s see memory management: there’s no explanation, just claims there are (or will be, it’s wip after all) no leaks, no gc, not refcounting, but also no manual memory management (it’s hardly leak free, after all, even in rust). What magic justifies that? Is there just no dynamic allocation? Otherwise I’d like to see the papers and subsequent Turing award for solving memory management once and for all.
        
        As for the deadlines: the author of V has made ridiculous deadlines so many times, for no good reason (why promise something in a few weeks or months instead of just waiting for it to be polished?!). It’s not like open source projects are tied to pointy haired boss deadlines.
  2. 13
    
    Corbin 3 years ago | link
    
    Interestingly, I’m not an “FP diehard”; I come from an object-based tribe, and I work on object-based designs.
    
    None of the listed improvements to V over Go are related to what makes Go bad; I have a thread from last year exploring the worst of Go’s flaws. In short, the problem isn’t even an upper limit on abilities, but a lower limit on how much code is required to do even the bare minimum, and a surprising lack of safety in common situations.
    
    As the original post author and several others have repeatedly indicated throughout current and past discussion about V, the speed claims simply aren’t being substantiated in an open and reproducible configuration which the community can examine and test themselves. Simply changing the host language does not grant speed, unfortunately, because of interpretative overhead, and the only cure is putting effort into the compiler.
    
    At the same time, it is toolchains and not languages that are fast, and so any novel speed improvements in V should be explicable to the rest of us. For example, in Monte, we use nanopass design and ANF style, originally explored in Scheme. We have a JIT in the Smalltalk/Java tradition, using an off-the-shelf toolkit, RPython.
    
    As an aside, I would imagine that V would be able to more efficiently take advantage of GCC/LLVM/etc. by picking just one backend, and emitting code just for that backend. This would be due to C’s relatively poor guarantees about how memory will be used.
  3. 5
    
    spc476 3 years ago | link
    
    V is translated to C before being compiled to machine code
    
    That, right there, is enough for me to question any safety guarantee V offers (and I like C).
    1. 4
      
      agent281 3 years ago | link
      
      Nim compiles to C and it’s garbage collected. I believe the reasons they do that are runtime reach and whole program optimization.
      
      If you can statically guarantee safety it shouldn’t be a problem. (However, its not necessarily a trivial thing to suggest.)
    2. 3
      
      r31r06 3 years ago | link
      
      ATS compiles to C too, if I understand it correctly. And there have been Haskell compilers that compiled to C too and many other programming languages that provide some aspects of safety that the underlying C language, like the machine code, do not provide.
    3. 4
      
      Hail_Spacecake 3 years ago | link
      
      Why does using C as an intermediate language in the compilation process necessarily imply that a language’s safety guarantees are bad? Compilers that compile to some kind of bytecode - like rustc compiling to LLVM bitcode, or JVM langauges’ compilers compiling to JVM bytecode - are perfectly capable of being safe, even though they output code in an unsafe language (which may or may not be the final compilation output - it is (I think) in the JVM case, but LLVM bitcode is further transformed into machine-specific machine code). I don’t see why C should be any different in this respect.
      1. 3
        
        spc476 3 years ago | link
        
        I don’t know the guarantees of LLVM or JVM, but at the language level, C has a ton of unspecified and undefined behaviors. Skipping the dangers around pointers and arrays, you still have the following undefined behavior as outlined in the C standard:
        
        shifting an integer by a negative value
        
        shifting an integer more than its size in bits
        
        left shifting a negative value
        
        signed integer representation (sign-magnitude, 1s complement, 2s complement [1])
        
        (quoting from the C99 standard for this one): Whether certain operators can generate negative zeros and whether a negative zero becomes a normal zero when stored in an object
        
        signed integer trap representations
        
        signed integer wrap sematics
        
        padding value
        
        padding in general
        
        reading a union member that wasn’t the last one written to
        
        Now, it seems that V is targeting GCC/clang, but even so, you’ll get differences in behavior across different architectures, specifically with shifting (some architectures will mask the shift count, some won’t). When I see “safety” as applied to a computer language, I would expect these issues will be spelled out as to what to expect.
        
        [1] In my research, there aren’t many systems in use today that are not 2s complement. They are:
        
        Unisys 1100/2200
        
        Unisys ClearPath A
        
        IBM 700/7000 series
        
        I know one of the Unisys systems is still be produced today and has a C compiler (which one, I don’t recall, I think the 1100/2200).
        
        2
        
        volt_dev 3 years ago | link
        
        you do realize that source code gets compiled to machine code, which is not safe by definition.
        
        The generated C code doesn’t use any of these, and doesn’t have to.
        
        3
        
        spc476 3 years ago | link
        
        Then what’s your definition of “safe” then? There is way less that’s undefined in assembly than in C. Give me an architecture, and I can look up what it does for the above list. The reason C has so much undefined behavior is precisely because it runs on many architectures and the designers of C didn’t want to favor one over the other. Different languages can make different trade offs .
  4. 5
    
    vegai edited 3 years ago | link
    
    FP diehards will never understand why Go has been so wildly successful – and V will be even more successful than Go.
    
    Do you? Go succeeded because it was created and backed by veteran Bell Labs people and Google, to solve existing problems. I’m not talking about marketing only, but also the level of sophistication and simplicity those people were able to bring in.
    
    It also succeeded because it didn’t promise anything it didn’t deliver.
    1. -4
      
      elimisteve 3 years ago | link
      
      Yes. I spotted Go as great technology in November of 2010. Go is simple and fairly powerful considering that simplicity.
      
      The original version of V was written in Go, V has learned many lessons from Go, both from its strengths that V builds on and the weaknesses it shores up with generic functions, generic structs, sum types, and more.

14

hydraz 3 years ago | link

I’d be interested in seeing what kind of these “lots of fixes in Generics are”, because as far as I can tell from reading the compiler source code, type errors for parameters in functions with a <T> slapped on them are still silently ignored…

  if !c.check_types(typ, arg.typ) {
    // str method, allow type with str method if fn arg is string
    if arg_typ_sym.kind == .string && typ_sym.has_method('str') {
      // note: str method can return anything. will just explode in the C compiler -- hydraz
      continue
    }
    if typ_sym.kind == .void && arg_typ_sym.kind == .string {
      continue
    }
    if f.is_generic {
      // ignore errors in functions with a <T> -- hydraz
      continue
    }
    if typ_sym.kind == .array_fixed {
    }

Try this code:

fn  foo<T>(y string) int {
  return 0
}

fn main() {
  foo(123)
}

-3

elimisteve edited 3 years ago | link

You had foo take a string then passed in an int :-)

EDIT: This works, for example:

fn foo<T>(y string) int {
  return 0
}

fn main() {
  println(foo<int>('hi'))
}

23

hydraz 3 years ago | link

… Yes, that’s my point. I passed an int to a string parameter, and the V compiler didn’t give a type error: the C compiler did.

% make
cd ./vc && git clean -xf && git pull --quiet
cd /var/tmp/tcc && git clean -xf && git pull --quiet
cc  -g -std=gnu11 -w -o v ./vc/v.c  -lm -lpthread
./v self
V self compiling ...
make modules
make[1]: Entering directory '/home/abby/Projects/v'
#./v build module vlib/builtin > /dev/null
#./v build module vlib/strings > /dev/null
#./v build module vlib/strconv > /dev/null
make[1]: Leaving directory '/home/abby/Projects/v'
V has been successfully built
V 0.1.27 b806fff

% ./v test.v
==================
/home/abby/.cache/v/test.tmp.c: In function ‘main’:
/home/abby/.cache/v/test.tmp.c:9476:2: error: implicit declaration of function ‘foo’ [-Werror=implicit-function-declaration]
 9476 |  foo(123);
      |  ^~~
/home/abby/.cache/v/test.tmp.c: In function ‘vcalloc’:
/home/abby/.cache/v/test.tmp.c:4597:1: warning: control reaches end of non-void function [-Wreturn-type]
 4597 | }
      | ^
/home/abby/.cache/v/test.tmp.c: In function ‘byte_is_white’:
/home/abby/.cache/v/test.tmp.c:7227:1: warning: control reaches end of non-void function [-Wreturn-type]
 7227 | }
      | ^
...
==================
(Use `v -cg` to print the entire error message)

builder error: 
==================
C error. This should never happen.

17
cadey 3 years ago | link
Author of the post here, let me see if I can try to clear some things up.

She cites vlang.io saying

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.

then argues against it, preposterously, by saying in part,

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. …

Downloading a .c source file requires git? Does this person know what a “dependency” is? Should JavaScript developers include depending upon the laws of physics in package.json?

Okay I was being a bit unfair, but if we look at the makefile we see that it has the following dependencies:
- make (which depends on perl, glibc, autotools and all that nonsense)
- git (which depends on perl (even at runtime), glibc, autotools and all that nonsense)
- gcc (which depends on perl, glibc, autotools, automake, autoconf and more libraries than I care to list right now)
So if you want to be completely honest, even if you cut out the make and git steps (which i care about as someone who builds packages for linux boxes using the unmodified build system as much as possible so I can maintain whatever shred of sanity I have left), it still depends on a C compiler to get bootstrapped. This is a dependency. Then you have to download the bootstrap file from somewhere, which requires dependencies in terms of root certificates and the compiler to bootstrap with (not to mention the server that hosts the bootstrap file both existing and serving the right file back). Given that V in its current form requires you to download files from the internet in order to build it, mathematically it cannot be dependency free (this actually precludes it from being packageable in NixOS, because NixOS doesn’t allow package builds to access the network, all of the tarball/assets need to be explicitly fetched outside the build with fetchgit, fetchurl and similar). Pedantically, requiring someone to have an internet connection is a dependency.

Pedantically, the v binary lists the following dynamically linked dependencies when using lld(1):
```
$ 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)
```
If the binary was truly dependency-free, the ldd output would look something like this:
```
$ ldd $HOME/bin/dhall
        not a dynamic executable
```
This leads me to assume that the v binary has dependencies that the runtime system will need to provide, otherwise the program will not be able to be loaded by the Linux kernel and executed. Binaries produced by v have similar limitations:
```
$ 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)
```
Additionally, I am banned from the V discord and GitHub. The V programming language has censored a neuro-diverse trans woman from being able to contribute to the project in any capacity. I would love to be able to contribute to things at least to make the documentation and website not filled with misleading statements, but I cannot. This is why I ask other people to make issues for me in my posts.

I realize things might look snarky when the article is viewed from a certain worldview/lens, but there is a total scalar lack of snark intended in that article when it was written. If you cannot realize that, then I am sorry that my intended tone didn’t have the effect I wanted and I will use this feedback to further refine my writing ability.

Direct x64 machine code generation

In my testing I was unable to get this working on my Ubuntu server. It still used gcc.
1. 8
  
  elimisteve edited 3 years ago | link
  
  You ended your piece (which utterly trashes V) by saying
  
  Overall, V looks like it is making about as much progress as I had figured it would.
  
  I criticized your snark, and you replied with
  
  I realize things might look snarky when the article is viewed from a certain worldview/lens, but there is a total scalar lack of snark intended in that article when it was written.
  
  Do you really expect anyone to believe that?
  
  Additionally, I am banned from the V discord and GitHub. The V programming language has censored a neuro-diverse trans woman from being able to contribute to the project in any capacity.
  
  Do you really think that’s why you were banned? Does Alex even know you’re trans? You don’t think you were banned for your vicious and misleading attacks on this project?
  1. 6
    
    formerly_a_trickster 3 years ago | link
    
    You’re just ignoring the points she made here, and keep talking besides her and banging on about the article.
  2. 6
    
    yorickpeterse 3 years ago | link
    
    @cadey didn’t say they were banned for who they are, they just stated they were X and were banned.
    
    You don’t think you were banned for your vicious and misleading attacks on this project?
    
    If my memory serves me right, @cadey was banned because of their disagreements with V, such as those voiced in this and the previous (https://christine.website/blog/v-vvork-in-progress-2020-01-03) blog post. I could be wrong. Also “vicious” is being overly dramatic and frankly not productive.
    1. 4
      
      elimisteve 3 years ago | link
      
      @cadey didn’t say they were banned for who they are, they just stated they were X and were banned.
      
      Then why bring it up?
      
      If my memory serves me right, @cadey was banned because of their disagreements with V, … . I could be wrong.
      
      Is that actually true?
      
      Also “vicious” is being overly dramatic …
      
      It doesn’t sound like you’re paying very close attention… Two other people criticized her for bullying in this very thread before I even got here. If you read my comments here then I’d hope you would change your mind about how unfairly harsh she has been to Alex, to his project, and to the V team.
      
      Consider starting here: https://lobste.rs/s/nfjifq/v_update_june_2020#c_vuofat
      1. 22
        
        friendlysock 3 years ago | link
        
        You almost never comment except in V threads.
        
        Further, many of those comments seem to be today, in last year’s thread.
        
        Please just let this be. Flag the submission if you must and move on.
      2. 6
        
        cadey 3 years ago | link
        
        I have removed the post as of this commit. In a few minutes the article will be gone, but a tombstone of the former article will remain.
        
        21
        
        hwayne 3 years ago | link
        
        I don’t think you did anything wrong by posting it, I don’t think you made any mistakes, and I enjoyed reading it. Not saying this to convince you to put the essay back; I just know that I personally feel awful when I get really harsh criticism, even when I don’t respect or care about the person giving it. So wanted to provide a bit of positivity to balance it out ツ
      3. 8
        
        yorickpeterse 3 years ago | link
        
        Then why bring it up?
        
        I can’t answer that question. While I’m not sure what the benefit is of bringing it up, I don’t see the harm either; it was pretty clear from the comment they were not saying they were banned because of who they are.
        
        Is that actually true?
        
        Feel free to show otherwise. I can’t, because I’m not the person who banned @cadey; nor am I in contact with them.
        
        It doesn’t sound like you’re paying very close attention
        
        Please do not make such assumptions. It’s unproductive starting an argument as such, as well as factually incorrect.
        
        Two other people criticized her for bullying in this very thread before I even got here.
        
        Only one person said it’s starting to look like bullying (https://lobste.rs/s/nfjifq/v_update_june_2020#c_cdxvwk). Other comments mentioning “bullying” either state they are not sure, or don’t see it as bullying. I don’t see anybody else mentioning this is bullying. Am I perhaps overlooking something?
        
        If you read my comments here then I’d hope you would change your mind about how unfairly harsh she has been to Alex, to his project, and to the V team.
        
        I agree the tone in the blog post is not the most productive. While some parts of the post are a bit pedantic, overall I think it’s not unfairly harsh. V made many big claims both before and after its release. Here are just a few examples:
        
        https://github.com/vlang/v/issues/35
        
        Translating C++ to V, which now has the note “TODO: translating C to V will be available in V 0.3. C++ to V will be available later this year.”
        
        Claiming V has pure functions when they can still have side-effects. “Pure” has a well defined meaning. If you mean “pure but with IO”, then call it something else; otherwise it’s just misleading. This was brought up in this issue, which was closed, but I can’t find any mention of this in the docs here.
        
        Various claims about certain components not having dependencies, only to have dependencies; despite the website advertising “Compiles to native binaries without any dependencies”
        
        Advertising “V is written in V and compiles itself in under a second.”, when according to https://fast.vlang.io/ compiling V with optimisations (if I’m reading the table correctly) takes over one second most of the time.
        
        There is a lot more from past discussions (e.g. those on Hacker News), so I suggest taking a look at those.
        
        With that all said, I really do hope V succeeds and wish the authors the best of luck. But the authors really need to make sure that what they advertise is actually implemented as advertised, or make it very clear what the current state is. Don’t go around saying “We support X” followed by “oh by the way we’ll release that end of this year”.