I would only partially agree that Kotlin is "much safer."
As one example, I just learned (by way of a nasty production app crash) that Kotlin chose to make all checked exceptions silently unchecked. Kind of a stunning own-goal for a language from 2010.
Oof, that feels like a blunder for Java interop, although I've never encountered use of checked exceptions in my admittedly limited Java experience.
In everyday Kotlin code, I see either a sealed class or Result for cases where you'd find checked exceptions in Java, and otherwise normal unchecked exceptions from `require`, `check`, precondition assertions.
The important distinction for me with Kotlin's system is that the compiler guides developers to write null-safe code by default because it's built into the language itself. Whereas Optional in Java requires extra effort in instantiating Optional.of(...) all over the place. Java Optional is opt-in, similar to (but weaker than) SQL `NOT NULL` - easy to forget, rather than Kotlin opt-out.
Even in safe languages like Rust, you can still introduce errors with the same semantics in application code as null pointer error: doing `some_optional.unwrap().someMethod()` will crash your program just as much as `someNullableObject.someMethod()` in Java.
The vlang team has repeatedly made false promises and assertions about what the language can do, ranging from a "we put things that are on our roadmap in our features list" to "we've promised something that is outright impossible". Analyzing how this has changed over the years, the only reasonable conclusion is that they're grifters who are okay with lying.
In addition, they regularly engage in flamewars about it on this site, and their moderation practices of silencing any sort of criticism in their own spaces and calling anyone who dares question it idiots are well known and documented.
Vlang has a Go to V translation project (Go2V)[1]. Usually vlang compiles to C (possibly aiming for a smaller and safer subset). This was a project focus[2] years before particular competitors, thus another hidden point, from which some of the drama springs from.
Additionally, vlang has other backends (ability to compile to other languages), such as JavaScript, WASM, native (in development), etc... There were contributors proposing having Pascal (Free Pascal variant) and Go as backend options too. There have already been discussions and experiments around creating V2Go libraries. Various developers appear to be waiting for the language to become a bit mature.
A lot of the hate or controversy is very artificial, where it's orchestrated and manufactured by vlang's adversaries. It's easy to see that people from all over the world are contributors to the project (785 at last count) and enjoy using it (36,500 stars). Along with numerous good reviews[1][2][3]. Clearly, those people are making no concerted effort to do anything sinister, other than continuous development or enjoying vlang.
As common sense will tell us, the only people likely to be upset about the language's consistent progress, are those who feel its a personal threat, have an axe to grind, or swallowed misinformation. Regular folks would not be worried or care, except about what they are using or working on. At the end of the day, it's a programming language, that we can choose to use or move on in life. It's really not or need not be anything more complicated than that.
I imagine the one they were thinking of was Rust, since it seems like that's more likely to be used where Go or C++ is, and it actually lets you use what are basically restricted pointers. But yeah, any language with an Option type that forces you to deal with the empty variant before you can use the data would have prevented it, including Haskell.
You can also just use a validation library of some sort such as go-playground/validator for Go and issues will sort themselves out by enforcing the loaded schema.
Do you mean Sytten's comment? I read that as joking we must be waiting for such safer languages to be invented otherwise we'd be using them, not as a push for a specific existing language itself.
Humor can be hard to interpret in text though as it inherently requires trying to read into the message alone, but that you could replace "like Haskell?" with dozens of options via the same assumption is the original point/joke.
