> proc identity*[T](x: T): T =

Personally, I still have symbol-overload PTSD from my Perl 4 days. When I see a flurry of that many symbols crunched together, followed by a dev saying "what's weird about them", I stay far far away from that language. Could just be me.

I was asking what's weird about the variable naming convention which the OP made a remark about.

You will actually find that Nim typically avoids operators. For example, boolean expressions use `and`, `or` instead of `&&`, `||`. I personally like that a lot.

Having to write `public` before every procedure would, on the other hand, be a massive PITA :)

I agree, I think ruby strikes the perfect balance between symbols and words, and I think that spirit has been kept alive in crystal despite it's syntax extensions. I truly enjoy crystal's "visual weight" (apart from proc syntax, thats just ugly).

Thanks Dom, Nim is a great language! <3

Dominik! Of course you are reading this. Your scope and level of activity is absolutely breathtaking. Thank you! I really do like much about Nim, I wish it every kind of success, and I probably will stick with it as my compilable language of choice - not that I imagine my sticking or not sticking is going to make any conceivable difference in the greater scheme of things. Trying to get up to speed, I have launched into what may be too heavy a web-app project for a beginner, and frustrations are beginning to mount as I hit a lot more conceptual walls than I expected to, and every now and again I can't help sneaking an envious look at the Crystal camp where syntax is easy, community is growing, spirits are high, and I can go from zero to banging out a respectable Kemal-app within 48 hours. At a price, of course, as it always turns out. There really is no such thing as a free lunch. The Nim tooling, as mentioned, is in a class by itself. Nim goes the sensible way of compiling to C, a far more efficient and transparent process than the LLVM route the Crystal folks have chosen. And it shows: Nim's portability is far ahead of Crystal's, and it produces better executables - smaller, a loss let brittle, and apparently more compliant. LLVM executables just often behave weirdly, like identifying themselves as "shared libraries", and going bust when UPX-compressed (which I do not need to do, but it's a tell-tale sign).

Anyway, let me try to address your points:

> Is there something you think Nim would be better without? Definitely, but these are entrenched features, and clearly not to be fiddled with at this stage: As hinted above, the sheer size of the thing, and the multiple ways there always seem to be to do whatever. Not necessarily a problem when writing code, but a real burden when trying to read it: "So what's a nice @ like you doing in a declaration like this?" "Oh, you're another way of declaring - or is it creating? - a seq. Which is sort of another way of declaring an array. Which has a couple of different implementations. Excuse me while I go and bang my head". Way too much of that stuff. Beginning with the alternative ways of seemingly each and every proc: Standalone and object-like, with a dot. I know this is meant to bridge the gap between us procedural folks and the object crowd. But it's still an obfuscation. It leads to disappointment, not least because at first look, Nim looks so deceptively clean and simple. In reality, I find the reading of Nim-code a lot harder than it needed to be. For my too heavy beginner project, I am porting some old Delphi code. And I mean old! I wrote it twenty years ago, and haven't looked at it since. Despite which, I have no trouble whatsoever understanding what it all means. But I do have trouble working out how best to represent my simple packed array[] of byte, what with the multitude of choices I have, though not a single one of them as concise and expressive as the Pascal, and all harder to comprehend after two weeks (as I discovered) than the original after two decades. I appreciate the enourmous dedication, knowledge, skill, and talent brought to Nim by Andreas and yourself, and whichever other core developers are out there, but damn!, I wish some useability freak had been consulted, and a lot of the heavyweight CS stuff had been kept solidly under lid and out of sight. There simply is too much unnessecary choice. It's overwhelming. And the overloading! This is a purely personal point of view; please ignore. But I don't like it, I never do. I see there may be use cases - that '+' might need to have a new meaning assigned in some new context, but to my uncomprehending eyes, that should be a hardwired lexer/compiler thing, never a userspace toy. And yes, I know just about every language does this nowadays. It's just that Nim-code seems to abound in it. And again, it hampers readability. A '+' should mean a '+', always, everywhere, no need to ever backtrack in order to understand.

>An easy rule to remember this is "the asterisk goes after the identifier" Yes, I sort of remember that now. But it's easily forgettable. And those poor characters - asterisk [how to escape in an HN comment?], @, #, !, etc. - don't carry any implicit meaning. Their use work against the ethos of Nim, at least as seen on the glittering surface. "public" or "export", or even just "exp" would do the trick, never mind the typing. If I wish to compress meaning down to arbitrary squiggles, I should go and code in C or Perl or some such nonsense.

>What's weird about them? [weird variable naming and casing conventions] That point has been beaten to death in threads all over HN, Reddit, and StackExchange. All the "this variable name equals that variable name, except when it doesn't, and give or take an underscore or two". It makes for uncertainty. The rules are sufficiently strange and arbitrary that I am never quite sure I remember them correctly. Like so many others, I should vastly, VASTLY prefer the way it's done almost everywhere else. With or without case sensitivity, but clear and unmistakable. It is not a huge problem, but it's a constant irritant.

>Please elaborate on this as well [arrays and seqs] I touched upon it above. I'm sure there is loads of clever, competent, unassailable reasoning behind the way things are done here. Me, a rather naive and superficial user, I just don't grasp it. Why do I need two very distinct types performing essentially the same function? And the array type in different flavors to boot, the fixed size and the open variety, each with its own incompatible set of behaviors? Again, like my other points, it's not a huge problem in itself, but all these double (and triple) options do add up, and [apparently] needlessly add to the burden of extra stuff I have to carry in my head. Clear and simple explanations of the need and rationale would go a long way towards making this acceptable. As it stands, it merely annoys.

>in the future please consider sharing this kind of feedback with myself or somebody else on Nim's team You are absolutely right, I am grossly remiss. I spew out my somewhat unqualified opinions in a place like this, but hang back from entering the lion's den - somehow thinking that as noob as I am, I really have no useful input to give. Right at the moment, I am insanely pressed for time and resources, but the instant I am rid of my present day-job, which I hate, I shall make an effort to participate much more actively in the community.

I just wanted to add to the arrays and seqs comment.

>Why do I need two very distinct types performing essentially the same function?

Arrays are very simple static blocks of memory and can be allocated on the stack, which is really fast, or at compile time. They can't ever be resized.

Sequences have overhead due to being pointers to pointers, however this means that they can be safely resized.

It sounds a bit like you're overwhelmed. Maybe the language needs a really paired down version of nim-by-example to explain these sort of things.

I actually understand that. But not from any docs I've seen. And then there are open arrays. But only as params in procs. Overwhelmed, nah, just occasionally annoyed. Mind you, I do like my world simple. Hence my envious looks at the Crystal camp.