1) 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.

It's true that compiler developers like krux, Clyybber, saem migrated to nimskull, I don't disagree.

> but there are only a handful of folks remaining that have been around for more than a year or two

But I totally disagree with your false statements about "senior" community members (those who don't do compiler development) migrating to nimskull - this is not true at all. There are a lot of "senior" people left in the Nim community.

And again, nimskull isn't a "silver bullet" either. It has the flexibility to change major things in the language just because it's a hard fork and almost no one (except people who develop it) uses it for real projects, whereas Nim has an actual userbase that doesn't want their code to be broken, especially considering the fact that nimskull has already removed a lot of the stdlib libraries, especially async (which there is no alternative to in Nimskull).

Are there experienced programmers in the Nim community, sure? Are they able to fix Nim with Nim's leadership in place? Doubtful in my mind based on history.

Also, I apologize if it seemed like I was evangelizing Nimskull or suggesting folks switch to it. I agree it is in no shape to serve a replacement for Nim presently, and may not ever be.

I'm sure fusion could have been handled better, and for 2021 the roadmap was a bit hazy, but I can't think of any other big missteps. Araq, dom, PMunch, and other senior folks are in the forms helping people and answering questions every day, and my interactions with all of them has been very positive. The big post 1.0 feature was arc/orc, and that was very well communicated. Bugs are being fixed, useful new features are being added, and future plans are being discussed in the open.

And Nim itself is great. The "if it compiles, it works" factor is high, yet I almost never feel like the compiler is fighting me. Simple things are simple (I'm teaching it to a group of 12 year olds), it's incredibly flexible, it's fast, and it's suitable for almost any sort of problem. There's nothing else like it, and I expect I'd continue using it for at least a decade even if it switched into maintenance mode tomorrow. I think it will take at least that long for something better to come along.

The point is the compiler has more and more cruft that makes it increasingly more complex and increasingly unreliable. It also makes it so that bugs are harder and harder to fix. Not to mention that it's basically impossible to track what is going on with the language at any given point in time because there is no roadmap or updated status. It also doesn't help that certain folks like to create ten GitHub issues and RFCs for every perceived slight in the language.

Once again, the problem boils down to a complete lack of leadership or interest in running the show - and instead of empowering the community to make that happen, leadership sits back and acts like everything is great and perfect and pats themselves on the back. When someone complains that it is not, leadership finds a way to defend itself and turn sentiment against the person complaining. It happens over and over again and it's why Nim isn't a success story like languages that actually have empowered communities and leaders that are interested in leading and not just collecting book revenues / making .io games, etc... while actively gatekeeping those who would like to get involved in making things better.

> 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

I don't think my totally normal usage of generics for type safety could be called "stretching the limits." My usage of generics includes using a parameter [V] for OpenGL meshes to introduce type safety with the vertex type. I'm pretty sure that's perfectly normal?

Recently one of my friends tried compiling my project - pan[1] on Windows, and for whatever reason - it doesn't work! stating that it "cannot instantiate 'V'", whatever that means. I've had this error annoy me many times before, but I have no clue what triggers it or how to reproduce it reliably. Call this a 'stable implementation.'

[1]: https://github.com/liquidev/pan [2]: https://github.com/liquidev/aglet

Generally it's not usually an issue with Nim's generics itself, but rather bad error message. Definitely an area for improvement IMHO. Though having used a fair bit of C++ templates over the years, I still find the Nim errors much more tractable after a bit of experience.

There _are_ a few broken limits of Nim's generics, but they are things pushing the type system to a limit.

A have a sinking feeling such language exists and is called "C".

It’s like the “incredible journey” term for companies that get swallowed whole by other companies, leaving their customers to dry.

Contrast this to, say, Zig, their road-maps and community structure is light years ahead.

It's not a coincidence you see the same name pop up, every time someone gets bullied out of the discord.

Have you ever dealt with someone that constantly lies and misrepresents your opinions to make you look like a villain? Have ever gotten frustrated, because the person you're arguing with is constantly shifting the goalpost to their benefit? Have you ever said something needlessly rude out of frustration? How would YOU react, if after dealing with all this disingenuous bs, YOU get told to watch your tone or you get banned for being toxic?

The justifications after a ban always make logical sense, true. But if you read through the logs with even a little bit of empathy, it becomes clear very quickly who the toxic person in those interactions is.

Edit: I'm not talking about a specific person getting banned. This happened numerous times, including newcomers.

I'm not even including the horrible software they've authored and cargo culted into the language's ecosystem and tooling. That should be enough of an offense to be removed from any decision-making role.

He didn't cargo cult his software into the ecosystem. He made the ecosystem. Nimble is the package manager because there was no package manager until dom wrote one. Jester is the default web framework because it was first, and despite its age it's still pretty good. Same for choosenim. And asyncdispatch. And all of the other tools/libraries that he wrote.

Obviously writing some early software doesn't give him a free pass. I could understand the attitude if he was a jerk, but I've never seen him be anything but helpful.

Try to advocate for replacing any of dom's tools / software packages and see what happens. Try to advocate for taking Nim in a direction counter to what dom perceives as the right one, even though they no longer contribute to the language anymore besides telling people to fix their broken software they're no longer willing to maintain, or to throw their weight around in RFCs / IRC.

This is the type of insecurity and paranoia one can expect to find when hanging out in Nim discord.

Another great section would be how to identify a pairing that is less than ideal / problematic.

You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile.

IMO - pair programming is over-hyped. I often find that I produce better, more reliable code, with the more space and more time I am given. I agree that pair-programming can rock in certain circumstances - but you need developers that have a certain level of synergy, you can't force it.

If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.

Motivation and desire to learn are partly function of personality and partly function of environment.

The tutorial method is thousands of years old, actually. I suspect that if one-on-one education was economically feasible it would be the model chosen almost every time.

Having paired with people who don't know what "if" and "for" mean in a software context clear through to individuals who've been in software for longer than I've been alive, I can only say that it works more often than not.

I often hear that pairing would be terrible at this, pairing must be dreadful for that, pairing wouldn't work for the other thing. What these have in common is that they are rejections based on mental simulation of events.

But ... I've actually paired. For years. It doesn't work for everyone but it still works for most people, so long as they learn it from an experienced pair.

It is frustrating to see a thing work, over and over, then be told you must be wrong, it can't possibly work.

It's also driven by the company. Sometimes companies make decisions that really impact employee loyalty.

On the other hand, in a review-driven situation, you're back where you started, multiplied by a slow feedback cycle and competing stimuli.

The current product I work on has had a team of - count em - two developers for the past year. I'm the one that is full-stack, so I get to help the less-experienced developer work on our frontend, while I have minimal time to work on the backend solo (for the most part).

My pair programmer partner, also has no interest in learning the new dev-sec-ops our company is pushing - so I get to also solo all of that work.

It's an extremely frustrating / soul-crushing scenario to be in. It's basically punishment for exhibiting competence and willingness.

It's a situation I'm hopefully out of in the next month.

I've been on and off anti-depressants since I was sixteen, and I'm 33 now. My self-confidence has been basically destroyed, and I've kind of been just a shell of a human being ever since middle school. I've never figured myself out, and I've never felt like I've had time to, or the space and energy.

I've been in and out of therapy, I've been to rehab, and I've seen lots of professionals - psychiatrists and therapists.

My current psychiatrist is helping me a lot - but it also seems like it's two steps forward, and three backwards. During the spring, I gained a lot of confidence, and felt like I was back on track, and it only took one thing going haywire in my plans, for everything to once again fall off the rails.

Like you - I finally broke down to my parents (who have been amazingly supportive over the years) - and this isn't the first time I've broken down in front of them - but hopefully it's the last.

I've decided that the career path I've sought for myself, which is the line of work they both worked in, isn't for me.

My main goal right now, which I'm going to need their help with (because at this point accomplishing basic tasks like opening my email / checking my physical mail - are terrifying to me), is to sell the house I purchased several years ago. This thing has been a boat anchor, and has helped keep me stuck by requiring a certain level of monthly income.

After that, I hope to quit my job and set out across the country to do some soul searching. Hopefully via the house sale and savings I've accrued, I can keep myself afloat for a while, while I pursue new opportunities.

My goal is to enter a new industry, that is arguably more rigorous than the one I'm leaving, but I feel like my current position has contributed quite a bit to my deterioration in mental health, and that it's not what I love - or even want - to do.

Ultimately, I keep myself going by remembering the alternative is not an option. I try to think that things will get better, but it's difficult at times. The one thing I can always rely on fortunately (and this isn't true for many), is family and my close friends. Networking is very important, and so is remembering that everyone, including you and me, deserves to be happy.

Your journey is yours alone to make, so don’t take this advice but rather an anecdote.

When I was able to better understand what I valued in life (which is also constantly changing) I was able to find a lot more peace in my day to day life. I do what I value. I avoid what I do not. Much of what I value comes with challenges, pain, and difficulty, but because I value it the friction proves beneficial in the long wrong. I eschew things I don’t value (social media), but constantly reevaluate and challenge myself.

Good luck. I hope you find what you’re seeking.

I really do value that feedback. I have also stopped using almost all forms of social media. I can't drop twitter - but that is because I value a lot of the content I read there (mostly related to game development).

I've also learned that I need to focus on what is important to my health, and less, on what is important to others.

These are hard lessons for some individuals to learn. It's amusing - because very much of my behavior is self-centered.

I think the key lesson I've learned throughout my continual growing process, is that thoughtless compassion and service to others, grants you the ability to also be compassionate towards yourself.

Living in your problems, hating life, focusing on negatives all the time, wraps your head around your own negativity and dissatisfaction with life.

It's a fine balance that needs to be maintained, and it's easy to slip up in that regard, but I think it's also critical in healing and recovery.

And even then - living this and thinking it, are two totally different things.

Your comment on the other hand...

Edit -

Sorry - that was rude. I should have elaborated.

Transpiling is a specific type of compilation that involves two languages with a similar level of abstraction.

Compilation involves languages with different levels of abstraction.

Nim offers a much higher-level abstraction than C, thus you could consider the process of converting Nim to C, a compilation process rather than a transpilation process.

Edit: Compiling def isn't wrong, but Transpiling is more descriptive to me as it indicates you're not going to assembly or machine language or something like that.

That's just how I look at it anyway.

Its standard library is improving with each release, and is already equivalent to what you expect from most modern programming languages. It contains flaws and inconsistencies, but it is being worked on and stabilized for a 1.0 release of the language. The ecosystem is small - but growing.

Some of the great things about Nim -

1) Ability to interface with C/C++/Obj-C/JS

2) Can compile to any of ^

3) Meta-programming

4) Python like syntax

5) Small binaries

6) Can compile to WASM via emscripten

I've built AWS lambda jobs with Nim by interfacing with Python, as prototypes for work, but I've never been able to leverage the language in production. I really only use it professionally to replace personal shell scripts or other tasks I've previously automated.

That said - Nim has a bright future - it needs to mature and hit 1.0 and it could really use some more interest as well as sponsorship.

Github - https://github.com/zacharycarter

That part is amazing. I personally do not have a real use case to exploit it [1], just find it neat from an engineering viewpoint...

I guess, it has an aggressive dead code removal process, compared to other - nowadays hot - compiled languages (Go, Haskell, Rust, D, Crystal). In those languages if you use a small part of their standard library, you usually get large chunks of it linked in statically (+ runtime if there is such)...

(Once I've tried LTO with one of my Rust project: it increased the build time tremendously but in the end it managed to shave off only 30KB from my several MB binary...)

[1] If I would try micro controller programming ever, I probably would give Nim a shot because of this...

Used -d:release --opt:size, then strip, Ubuntu 16.04 64 bit. The binary sizes:

GTK2 example code: http://rosettacode.org/wiki/GUI_enabling/disabling_of_contro... - 35k

http client: http://rosettacode.org/wiki/Ordered_words#Nim - 72k

http server: http://rosettacode.org/wiki/Hello_world/Web_server#Nim - 121k

The binaries are dynamically linked only to the common standard C prog. dependencies on Linux: linux-vdso.so.1, libc.so.6, ld-linux-x86-64.so.2 (Except for the gtk2 example of course, which uses libdl to to pull in a large bunch of additional gtk dependencies too...)