carterza (u/carterza)

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

Ye gods and little fishes, is there a new-ish language suitable for application programming, which has a more-or-less feature-complete design and implementation, and where there's no petty drama going on every other day? And which, to boot, lets you get a job done without requiring/strongly suggesting that you become a part of their vibrant community?

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

carterza · 4 years ago

You may be right... I wouldn't call Nim's community vibrant though.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

HiddenBek · 4 years ago

Nothing here is untrue, but from my perspective it's overstated. I don't use discord, but I visit the forum daily, follow most of the RFCs, and spend a lot of time coding in Nim (https://github.com/dsrw/enu). I really like Nim, mostly like its community, and think many more people should be using it.

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.

carterza · 4 years ago

The compiler works until you stress the type system or try to take advantage of features that are experimental and then stay that way forever. How many iterations of concepts have we been through at this point? What happened to hot code reloading? Why do we have all these legacy GCs?

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.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

dsrw · 4 years ago

I haven't seen this at all, and am actually baffled that you're talking about dom. My experience of him has been the literal opposite.

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.

carterza · 4 years ago

I mean, I have experienced first-hand, dom96 being a jerk directly to me after I spent months of effort building something for the community. I'm not the only one either. If it was just dom96 being a jerk my criticisms might not hold water, but the problem is far deeper than that.

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.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

planetis · 4 years ago

I agree to some extend and that's why I believe bans should be lifted after 30minutes when people have calmed down. But on the other hand one should watch how he behaves and not blaming it on others.

carterza · 4 years ago

dom96 simply needs to go - they are nothing but self-serving and they cause more damage to the Nim community than any other member by far.

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.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

SolitudeSF · 4 years ago

its true that leadership does nothing and development is stuck, but even in this state nim is probably enough for most people.

> 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

carterza · 4 years ago

I'm not sure there is one - but I guess a language where you're not constantly dealing with horrible error message, an under-specified and broken implementation and a shitty stdlib - might be better, even if it doesn't have some of the nicer frills of Nim.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

Tiberium · 4 years ago

> many of the more senior community members or those who have been around for a bit have migrated there

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

carterza · 4 years ago

I guess your definition of senior and mine vary. I'd consider senior members anyone willing to work on the compiler, as they are the members with the potential to move the language forward and out of the mess it currently finds itself in.

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.

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

PMunch · 4 years ago

Most of the "senior" community members who have migrated to NimSkull are those who liked to work on the compiler. The ones who remains using Nim are those who like to write libraries and projects. I've yet to see anyone create a library or project with NimSkull, although that might be because I'm not too exposed to it. I would love to be proven wrong, but for the time being NimSkull looks like a good idea if they can pull it off. But currently it looks like ripping of the band-aid to get to a better place and currently it's still in the burning and stinging phase before things (hopefully) gets better.

carterza · 4 years ago

I apologize if my sentiment came off as Nimskull is a realistic alternative for those who are frustrated with Nim - it certainly is not, and I think your description of the state of the project is spot on PMunch!

carterza commented on Nim Version 1.6.6 Released nim-lang.org/blog/2022/05... · Posted by u/shaftoe444

carterza · 4 years ago

I 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 Nim, which I'll outline briefly below.

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.

carterza commented on The case for pair programming tuple.app/pair-programmin... · Posted by u/mijustin

mbo · 7 years ago

The "How to pair with a junior developer" section is extremely considerate, and highlights some behaviours that I know I've subconsciously engaged in that may have negatively impacted a junior dev. Expanding this section would be great.

carterza · 7 years ago

I'd also like to see a section for junior devs, and what they need to bring to the table.

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