There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason
People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.
Nim Version 1.6.6 Released
71–80 of 116 posts
Re: Nim Version 1.6.6 Released
#72Earlier quoted context omitted.
The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python. And I'm not certain what scenarios you envisage where this would be an issue, why do you c…
Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main... I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo…
Like this:
type FooManager = object
var foo_manager: FooManager
> Now... are these colliding? Or not, because the first letter _is_ case-sensitive?Well as you correctly reason, the first letter's case distinguishes them.
Convention in the language is for types to start with a capital letter and instances start with a lower case letter.
> What does "fooManager" map to then?
It maps to the `foo_manager` instance because underscores are ignored, they're just for you. By the way, underscores are exceedingly rarely used in Nim code because they're not semantically significant, why bother.
Still, if you like you can use them in your code, and others can choose not to as they want. Clashing identifiers are a compile error so no worries.
Re: Nim Version 1.6.6 Released
#73I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…
It's not clear to me what they could do. In the thread you linked, it's not just the binaries of the various nim executables, but also user generated binaries. And it appears that even signed binaries are getting flagged by some vendors. I'm guessing the issue is that some malware writers started using nim, and the antivirus vendors then decided to make heuristics that detect nim generated binaries and call it malwar…
Probably best to select the top 10 AV companies, to keep the workload down. Per each release, shouldn't be too bad, though likely someone or a group needs to be designated for the task.
Re: Nim Version 1.6.6 Released
#74A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.
It sounds to me like you might enjoy SML or OCaml.
Re: Nim Version 1.6.6 Released
#75Earlier quoted context omitted.
Yikes, does that mean scumbags could effectively torpedo any new language, like Zig and Hare, for example?
Yes, but it's not like this only happens with small/new languages. Even today, Go-lang binaries will often get detected by various Windows anti-malware software. They even have a section in their FAQ about it [0]. Also, in Hare's specific case, it doesn't _really_ matter as they will never support Windows or MacOS [1], and there isn't a significant presence of anti-malware software on linux distros. [0]: https://go.d…
Re: Nim Version 1.6.6 Released
#76Earlier quoted context omitted.
Yes, but it's not like this only happens with small/new languages. Even today, Go-lang binaries will often get detected by various Windows anti-malware software. They even have a section in their FAQ about it [0]. Also, in Hare's specific case, it doesn't _really_ matter as they will never support Windows or MacOS [1], and there isn't a significant presence of anti-malware software on linux distros. [0]: https://go.d…
Not supporting Mac is a big shot in the foot from Hare. Is this a case of ideology getting in the way of pragmatism, or do they have technical reasons? Singling out proprietary platforms sounds ideological.
Re: Nim Version 1.6.6 Released
#771) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed.
2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community.
3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project.
Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull
Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them.
My advice would be to look elsewhere.
Re: Nim Version 1.6.6 Released
#78Earlier quoted context omitted.
People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.
What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
Re: Nim Version 1.6.6 Released
#79Re: Nim Version 1.6.6 Released
#80I started programming in Nim around 2015 and still write code in it from time to time. At this point I would have a tough time suggesting the language to anyone for much. While you can certainly accomplish almost any programming task with Nim, how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off. There are other major warts with…
> how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off.
unless you limittest generics, most people wont even encounter this.
> My advice would be to look elsewhere.
that would imply that there is a better alternative