The topic has been drifiting away from technical merits, design, ergonomics or
even marketing strategy. I think it's time to let it rest.
I did use assembler on the commodore 64 a long time ago producing 6502
machine code, but for now ill stick with Nim but maybe switch to Pascal (I
tried Python, Perl, Rust, Fortran, D Language) if Nim cannot do what I need.
Thank you for your input :-)
> 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.
Vlang? Does the V stand for Vile? ;-) AnywayJeez what language next...cos
we have... Golang, DLang, VLang…. hows about BamaLang, then we'd just need the
Ding Dong language and we'd have (yes you guessed without regex)…. Bamalang a
Ding Dong!! :-)
> [It](https://github.com/vlang/v) has 1k more Github stars than
> [Nim](https://github.com/nim-lang/Nim).
Yet another reminder that [GitHub stars are an awful harmful way to
measure](https://old.reddit.com/r/nim/comments/8q99ba/happy_5000_stars/e0i7etu/)
anything...
> BTW, Nim is approaching
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, th
{.push: sarcasm.}
I'm getting tired of all the bikeshedding in language comparisons on:
* significant whitespace
* camelCase vs snake_case
* module imports and namespacing
* garbage collector
So I propose a new set of bikeshedding topics:
* Inclusive upper range `..`
* operator ov
> 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. Everythi
Look at how many bug labels you see on the issues page... Nothing against that!
But that guy is so ultra convinced of his language being king and yet it is
just another language with all the same issues, as others had and may have.
That's sad :-( But it shows the power of advertising...
It has more 1k Github stars than Nim.
There goes my "V is for [Vaporware](https://en.wikipedia.org/wiki/Vaporware)"
joke... 🙄
But on the other hand I do defend the author. Being overly ambitious and slow
to deliver can annoy people, but there's still potential for long-term success.
In the meanwhile the V language was released to github. Which is quite funny. A
lot of people gets upset not seeing bold claims actually being well implemented.
[https://github.com/vlang/v/issues/35](https://github.com/vlang/v/issues/35)
> Lack of significant whitespace improves readability and maintainability of
> large code bases (...)
Unless somebody provides a good research on this topic, I dare to say, that it
is total BS.
BTW, many people complain about syntax with significant whitespace, and still
use whitespace to inde
> I'm pretty sure you're joking, but that's absolutely not what the Nim
> community should do.
Thank you for picking up on this @bpr. I definitely wasn't serious and I agree
with your points 100%.
> function main is undeclared in the main module.
Cool example you got there. Personally speaking, once you go full identation,
you cannot go back.
V's announcement was too early for April Fools and now it's too late. Maybe
next year?
On the other hand, I found Alexandrescu's "iterators must go" slides by
browsing the V issues, and I think it's a perspective worth sharing:
[https://accu.org/content/conf2009/AndreiAlexandrescu_iterators-mus
There are right ways and wrong ways of comparing languages. The right way is to
treat both of them respectfully and compare them as different approaches and
different styles, while still highlighting particular things that each excel at
or elaborating on why they made different design decisions.
There is nothing to talk about until the reference compiler is released.
"Talking is cheap, show me the code" (c)
> 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](https://vlang.io/compilation_spe
> 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 ex
> 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:
* Spreading FUD about the language they compare against
* Attracting people to try the language th
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% bike
Unfortunately the main dev doesn't want operator overloading.
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
LOL, minutes ago I happened to mention Vlang [on another thread of this
forum](https://forum.nim-lang.org/t/1996) (before seeing this thread):
> [...] [Vlang.io](https://vlang.io). It's not even released yet (except online
> playground), but I do like the promised features and syntax, as a refug
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
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 most
[V Language](https://vlang.io) author wrote about differences between Nim and V:
[https://vlang.io/compare#nim](https://vlang.io/compare#nim)
I would love to hear some comments on this from the Nim community.
29 matches
Mail list logo
