Compared to Go, taken from [1]

V is very similar to Go, and these are the things it improves upon:

- No global state

- No null

- No undefined values

- No err != nil checks (replaced by option types)

- Immutability by default

- Only one declaration style (a := 0)

- Much smaller runtime

- Much smaller binaries (a simple web server written in V is 65 KB vs 7 MB in Go)

- Zero cost C interop

- No GC

- Much faster serialization using codegen and no reflection

- Precompiled HTML templates unlike html/templates that have to be parsed on every request

- Fearless concurrency (no data race guarantee at compilation)

- Enums

- Generics (in July)

- String interpolation: println('$foo: $bar.baz')

- Stricter vfmt to ensure one coding style

- Centralised package manager

[1] https://vlang.io/compare

Global state is a feature, not a bug. It's absolutely necessary for a number of application domains and disallowing it by design makes the V language totally unsuited for them

I'm guessing you still are able to use a singleton, no?

Singletons still require globals. I haven't really dug into V that much, is there a mechanism to make a singleton? If so, how can they claim "no global variables?"

I'm curious, can you make an example?

POSIX signal handlers don't take an argument other than the signal code, so if you want to handle them gracefully in a stateful app you need a global to communicate the trapped signal to your main loop.

Closures could be used to implement this use case, provided that they can be exported/represented as native C function pointets, e.g. via a trampoline that captures the necessary captured context)

How would you implement the trampoline without a global? And would the captured context not count as a global?

In C the only memory available to a function is its arguments and data with static duration. That static storage is synonymous with global state, if it isn't known at compile time.

We have to distinguish what the given language exposes to its users and how the code such language generated works on the underlying hardware (along with constraints due to compatibility with other languages, most importantly C which is the de-facto system interface nowadays).

A C-compatible closure basically requires an executable chunk of memory that captures the state along with the istructions to push it to the parameters area (based on the architecture's calling convention) and then jumping to the actual function.

This is not global just because it's scoping the state with the function. On the other hand it becomes global the moment it gets installed to a global handler table (because there can only be one such handler).

However a language that limits globals (and forces people through this kind of hoops in order to deal with cases where singletons are really needed) encourages a coding style that makes it easier to test your code in isolation.

Eh, not a big deal.

Just move "global" (aka: main() ) up 1 function. And then, run everything in that function. Hell, it could be a try-catch loop equivalent.

That kind of assumes you have a main() function.

There is not a single situation where global variables are necessary.

Global logging in libraries is not uncommon, especially if you need to trap signals (which can only interact with global state).

COM APIs expose a global class factory as the main interface to a shared libraries.

Embedded systems and drivers require globals in one form or another.

"Globals are evil" comes from the fact that globals have side effects, and side effects make things hard, especially in modern software that utilizes asynchronous/concurrent logic. That just makes them unwieldy, not unnecessary. Especially when interacting with legacy systems that require globals.

I take it you've never programmed embedded?

Yeah, state sucks. But sometimes, you need a starting point, and diff from that. And, that's state.

One of the safe ways of handling global vars, is by having only a single non-interruptible function that can mutate global. And you have best make sure your global-mutating function is fast. You don't want to miss IRQs that might fire off but are blocked.

Yes, embedded is enough of a special case that I don’t consider it as part of a general purpose discussion on programming languages.

Ericsson predicts 18 billion IoT devices by 2022. Those all need code written for them. Do you still consider embedded programming a "niche"? Maybe it's one specific case, but it's relevant and ought to be "part of the discussion".

https://www.ericsson.com/en/mobility-report/internet-of-thin...

> No GC How does that improve upon Go? Memory safety is much harder without a GC

GCs are good for some things and bad for others. I wouldn’t want to write an OS with a GC but I also wouldn’t want to write a web server where I have to manually allocate and free memory. It’s all a trade off.

You shouldn't be manually allocating memory anywhere if you malloc and free. I feel quite strongly about the use of C in modern systems code: The "C" way of doing things can often be very unsafe or at least prone to being unsafe (No fault of the programmer, but if you don't provide RAII and things like that by default it becomes too easy to double free or leave bounds unchecked)

A kernel doesn't really need a garbage collector, but keep in mind that some modern GCs can literally be tuned to have ms pause times on absolutely enormous heaps which given that reference counting can have unbounded pause times too can make them an enticing option.

The real reason to avoid garbage collection is typically memory usage in my experience

Yeah, I was using “manually allocating” as a synonym for malloc and free, but they are actually different things.

Isn't it usually game programmers who advise against GC because you can't predict when it will run and the performance impact it will have.

Game programmers and also people who seem to think that Garbage Collection involves burning babies and the hundreds of academics and engineers working on it are somehow doing it out of spite.

There are reasons not to use a Garbage Collector but 99% of the time they are absolutely fine if you understand what your particular GC does and does not do

It is not in my opinion. With modern development tools/frameworks providing memory leaks detection I have completely forgotten when was the last time that my programs leaked memory. And I write complex high performance game servers that run for months non stop. You just have to acquire certain culture/behavior when writing code.

All the code I write at the moment is GC-free (By circumstance), but it's clear that not using a garbage collector is a tradeoff between runtime nondeterminism and the complexity of the code (How many of Herb Sutter's talks on smart pointers could have been eliminated if C++ had a garbage collector available, for example) or compiler/language complexity

What languages/tools/frameworks/behavior are you using to develop these game servers with no leaking memory?

for c/c++ I use Visual Leak Detector and Valgrind. For Delphi/FreePascal/Lazarus there are built-in tools and also MadExcept . Behavior/patterns are different depending on task/language but generally when writing code if I want to allocate anything I first write deallocation code.

I've found valgrind and the clang static analysis tools to be a pretty nice combo.

Also, Garbage Collection can be extremely fast when done properly: The Decision to use a garbage collector could be done on performance grounds as well but Garbage Collectors are generally harder to tune than reference counting.

What tools for memory leaks detection you can suggest?

Valgrind (Which also has a bunch of other stuff like cachegrind, which can be a godsend if you are getting telltale cache/branch prediction issues but you can't find where etc.).

Clang/GCC both have suites of sanitizers which are usually excellent and easy to grok, these are also available in many language frontends based on LLVM (and maybe GCC?)

You can just throw every tool you can find at your CI if you're paranoid, too.

You can read about differences here: https://vlang.io/compare