V Language author wrote about differences between Nim and V:
I would love to hear some comments on this from the Nim community.
I think he left off the most important comparison: Nim is actually available while V will be "open source mid 2019." I'm really curious about V and applaud what the author is doing, and I am eagerly looking forward to trying Volt when it's a little more stable. The comparison he wrote is is mostly based in reality, but it's also a little... optimistic.
V's syntax is a lot cleaner with much fewer rules. Lack of significant whitespace improves readability and maintainability of large code bases and makes generating code much easier.
That's an... interesting take on whitespace.
(Particularly since all the V example code includes whitespace exactly where you'd find it in Nim or Python, whether it's required of the language or not.)
There are certainly arguments to be made against syntactically significant whitespace, but those arguments aren't really being made here.
The list can go on and on. Nim is a language with a lot of features, still developing and changing. V is not going to change much, if at all.
This comes across as naive to me. It's a language that's currently used by 1 person (from my understanding) on a small handful of projects. It probably works great for those use cases as they are but once it hits the real world and other people begin to use the language there will almost certainly be changes. And if there aren't those other people aren't likely to use it. (Which is perfectly fine, except that the author wouldn't be writing these comparisons if he didn't want others to use V.)
Change is neither good nor bad, it's simply a sign of evolution and growth.
My (insignificant) 2cent ;)
V and Nim are very different. One of V's main philosophies is "there must be only one way of doing things". This results in predictable, simple, and maintanable code.
This is fallacy. Bad written code is bad, no matter what syntax is. The only thing that make the software maintainable is documentation.
Predictability is something resulted by how clear the program (or data) flow from start to end. Not the syntax of anything or what.
Simplicity comes after several (endless) iteration of how we write the software. Hoping to write program with simplicity at first shot? Without even understanding the nature of problem we want to solve? Well, good luck with that :D
LOL, minutes ago I happened to mention Vlang on another thread of this forum (before seeing this thread):
[...] Vlang.io. It's not even released yet (except online playground), but I do like the promised features and syntax, as a refuge from the growing complexity of Nim. I'd call it "Go done right", or "Go for people who hate Google". 🤓
One thing that Nim and Vlang have in common is that I've license-nagged both into s/GPL/MIT/. 😁
The comparison is terrible and almost every sentence is dubious.
Features like macros and OOP offer even more ways to solve problems and increase complexity.
Maybe there is a reason why many other new languages like Julia, Elixir, Rust also have macros.
I'll post a detailed article about the power of immutable strings.
Spare me, I know the advantages and disadvantages and mutability wins whenever you start to optimize the string handling and stop passing them around pointlessly like they are cheap. They are not. Yeah, yeah, I know, I know, you don't have a GC but "automatic MM", so you use atomic reference counting for strings ... which is slow: https://jjacky.com/2013-03-16-strdup-free-vs-atomic-reference-counting/
On top of that the mutable strings give us consistent language semantics, you know, this thing most programmers keep confusing with syntax.
Nim allows importing functions into global namespace. This becomes a huge problem when working on large code bases. Explicit imports that V, Go, Oberon have are much more practical: pkg.function() vs function().
You're free to write pkg.function everywhere. But not everybody spends the day musing about where stuff has been declared, some people can use an IDE effectively and actually fix bugs instead and work on new features. I dunno.
It's also possible to embed C code in Nim, which reduces safety and portability.
Sure, much like having legs is bad since you can break your legs.
This is a small segment copied from a simple hello world program:
Sure, show something from a debug build and don't show us the produced assembler.
This must be one of the reasons it compiles almost 100 times slower than V.
Or maybe it's because Nim is more effective than V at solving the problems it was designed to solve. Not everybody believes in programming language designer fascism.
V's syntax is a lot cleaner with much fewer rules. Lack of significant whitespace improves readability and maintainability of large code bases and makes generating code much easier.
"Much easier"? No, and just one minute ago you indirectly claimed that producing "readable" C/machine code is an advantage so you better produce code with the whitespace anyway.
The list can go on and on.
Yeah no shit, please go on since so far no convincing argument has been found.
I've never been a fan of these language comparisons, regardless of how they turn out. They always pick some factors that the author considers big selling points, but may be either irrelevant, important, or actual negatives from the reader's perspective. And this particular comparison is 90% bikeshedding, so it doesn't tell me anything I'm actually interested in.
Actually comparing languages is something that I don't think is really possible in a way that is informative. Programming languages and their runtimes are not suitable for a feature-by-feature comparison; most of their features are too interdependent to be looked at in isolation.
I've never been a fan of these language comparisons, regardless of how they turn out.
@Jehan you might not be a fan, but I'm willing to bet that these comparisons work in doing two things:
It sucks that our industry is so filled with hype, but that's what happens. At the very least the author of V should link to this thread to allow us to debunk their points.
FWIW we actually do pretty well on the compilation speed: https://vlang.io/compilation_speed. Perhaps we should spread some FUD about Rust taking hours compiling 400k LOC?
But you know... perhaps we should spread some FUD about Rust taking hours compiling 400k LOC?
I'm pretty sure you're joking, but that's absolutely not what the Nim community should do. Engaging in pissing contests like this is counterproductive. I'm quite sure that Rust fans can find examples where Nim looks awful compared to Rust.
I believe it's possible, even necessary, to engage in language comparisons, but it's very difficult to do well, and the example from the V author is IMO very far from optimal. I hope that he can do a much better job in the future.
Spreading FUD about the language they compare against
Yeah, that's a big part of why I'm not a fan. They never reflect the actual experience of using a language.
FWIW we actually do pretty well on the compilation speed: https://vlang.io/compilation_speed. I find it incredibly unlikely that this benchmark hasn't been gamed in V's favour though, 0.6s?
It's not gamed, but the small print has been omitted. Basically, V has two compilation modes. One is a dumb tcc-style compiler that doesn't really optimize anything, the other is to compile to C (like Nim). You get the fast compilation speed by basically having a very fast backend and a language with simple semantics.
Problems:
BTW, many people complain about syntax with significant whitespace, and still use whitespace to indent code in blocks, denoted with some parenthesis...
Not speaking for V's author, but if I was the one making the claim he made I don't think it would be related to indentation at all. Everything has its pros and cons, but I can think of more pros and less cons for lack of significant whitespace than for significant. In this case the pros of one are the cons of the other.
A language with block delimiters can actually improve readability, since it gives you near total freedom to decide how the code is visually organized. It's obviously down to you to not make an even bigger mess of it, though.
For some people having the braces delimiting stuff helps their eyes make things out better. We all have different ways of interpreting what we see, and we're all used to different paradigms. When I first started using python, I found it visually confusing. I was coming from C++ and Haxe.
In some cases I find it useful to economize on vertical space (because monitors are wide, not tall). So for example, when you have a big switch/case or a bunch of if/else ifs, sometimes you can pack each of them into one line, so it all fits on the screen, and also so that you can easily edit several lines at once. You can't do this in python if you have more than two expressions inside the if. (I never tried it in Nim.)
It's also useful for cases where you need to temporarily comment out a loop's header or an if's condition, such that you don't have to waste any time rearranging the indentation of the code block that was in it to make the compiler happy.
On the other hand, significant whitespace means a bit less typing, and maybe on the whole it may end up economizing on the vertical space more. I can't think of any other advantages.
(I guess how important vertical space is to you will depend on how big the font you use is.)
{.push: sarcasm.}
I'm getting tired of all the bikeshedding in language comparisons on:
So I propose a new set of bikeshedding topics:
{.pop.}
Wasn't trying to fuel a discussion over it. I was just saying. I wasn't even comparing languages, just two paradigms, and in the context of clarifying that maybe the reasoning people follow with regards to that paradigm is unlikely to be conflated with indentation. Credit where credit is due, the V guy may have a point on that one.
On a related note, my experience made me more favorable towards braced-code, and yet here I am using Nim, GDScript and Python (and Lua), and completely dumping C/C++/Rust/Haxe/D/Java/JS/C#/etc.
Yet another reminder that GitHub stars are an awful harmful way to measure anything...
BTW, Nim is approaching 1000 nimble modules! 🎂🎉🎆
what language next...cos we have...
If you think that we do not need new computer languages and you do not appreciate the hard work of languages developers, then you are free to use binary codes, or maybe assembler, cobol or fortran.