While I disagree with the person you're replying to, I find your reply dismissive.
I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience.
Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehensibility[1]) ecosystem in itself. It's not like "docker" or "kubernetes" where you're mostly dealing with "data" files like yaml, json or Dockerfile. You're dealing with a complex programming project.
With that in mind:
- You have a core team with 1 or 2 people with Nix passion/expertise.
- Those people do most of the heavy lifting in implementation.
- They onboarding the team on to Nix
- They evangelize Nix through the org/company
- They mod and answer all the "#nix-discussions" channel questions
Initially the system is fairly successful and everything is good. over the next 5-6 years it would accumulate a lot of feature asks. The original "Nix person" has long left. Most of the original people have moved either to other projects or not particularly that passionate about Nix. In fact, the "best" developer you have who has inherited the whole Nix thing has only really had to deal with all the shit parts of Nix and the system. They are they ones fixing issues, dealing with bugs, etc. All while maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack.
Eventually that person/team that's annoyed by maintaining the Nix project wins. They want to own that code. They don't want to use Nix any more. They know what's needed, they want to implement it as part of their main Go stack that they are actively working on. They can optimize things for their special case without having to worry about "implementing it the Nix way" or "doing it upstream".
They promise you (the management who is open to the idea, but trying to understand the ROI) feature parity + top 5 feature asks for the initial release. You trust the team enough to let them do what they think is best.
[1]: LLMs are really good at suggesting a solution given an error message. Nix errors bring them to their knees. It's always "Hmmm.... it appears that there is an error in your configuration... have you tried a `git revert`?"
I'm not being dismissive. Well, I am dismissing a lot of industry people's opinions. Because they're bad.
Just because people decide stuff for money doesn't mean I can't call them bad. Not everyone is equally skilled.
And your parable is exactly the issue. The unskilled and loud and whiny do often win, and it's a shame. I see it all the time.
(Also you're way overstating Nix as a "full blown FP language." It isn't hard to learn. I learned it just be existing on a project with it. Within 6mo, now I'm apparently a "Nix expert" and people now point at me as one of the people who "knows it" and "you can't expect everyone to know it like you do." idk maybe I'm some genius but I think it's more that I just don't have a bad personality.)
So you are being dismissive. That's what you're doing. You're dismissing more than just "stuff for money". You're dismissing anything that doesn't fall under the "skill" or "technical" category. All software projects contain a human element. I was showing an example from my experience on how something like that could happen.
> A perfectly capably (but perhaps a bit esoteric) technology is picked by a smart passionate person for a project.
> The novel technology is in 1 isolated module that's mostly feature complete for the first 1-3 years.
> People in the team/company deal with that "thing" as a blackbox more and more
> 5-10 years later, mostly new team maintaining the project. They hate the weird choice of tech. "Why is only this one component different???"
> People understand the contract with the "black box" very well, but HATE the "black box". People think "We can implement the black box contract very easily"
1. Someone was forced to maintain Nix and want to switch to easier to maintain tooling
2. That someone can lack in technical understanding of the problems they are facing
The former doesn't negate the later.
The way I would put it is sometimes you choose a worse option because the people you have available are better at that option. That doesn't mean you made a mistake but it does mean your lack of expertise sent you down a different path.
And of course to finalize I will re-emphasize my "didn't make a mistake" comment. Ivory tower isn't a good idea either.
But someone responding "it is too bad the company that built packages couldn't properly use the package tooling they depended on" can still be true in a situation where a company made the correct decision of dropping that package tooling.
Yes I am dismissing. People don't have a right to not be dismissed if I judge them poorly. People are allowed to have bad professional opinions of others.
And I am dismissing the types you describe specifically. I dismiss them (privately amongst the likeminded) at work all the time too. I just put them on a list in my head when they start spouting these sorts of bad values.
> maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack
Nix is a package management system with a little bit of programming tucked onto the side. "Nix stack" is not the same type of thing as "Go/Rust stack". If you try to move things over to Go/Rust, you'll spend a little bit of time rewriting the code and a whole lot of time reinventing the wheel on everything else involved. You're not moving between implementations, you're building your own implementation. That's almost always a bad idea, and it's a much higher cost than learning the syntax.
Moving from a Nix stack to a Go stack only makes slightly more sense than moving from a docker stack to a Go stack. Which is to say, very little sense.
Wow, this is literally the story of my team. Luckily there’s enough autonomy for us the escape the gravitational pull of the few remaining evangelists, but this is essentially what led us to this point.
I think that's kind of sad. There are a lot of good technologies that require some investment to understand them and a lot of worse is better approaches that end in a mayhem that is ultimately a terrible work environment.
For a while it seemed like investment would win but now I think we will have massive tombs of poorly written stuff that can only be worked around with even more LLM generated solutions. It is like the software bloat problem we've had recently but on steroids.
While I disagree with the person you're replying to, I find your reply dismissive.
I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience.
Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehensibility[1]) ecosystem in itself. It's not like "docker" or "kubernetes" where you're mostly dealing with "data" files like yaml, json or Dockerfile. You're dealing with a complex programming project.
With that in mind:
- You have a core team with 1 or 2 people with Nix passion/expertise.
- Those people do most of the heavy lifting in implementation.
- They onboarding the team on to Nix
- They evangelize Nix through the org/company
- They mod and answer all the "#nix-discussions" channel questions
Initially the system is fairly successful and everything is good. over the next 5-6 years it would accumulate a lot of feature asks. The original "Nix person" has long left. Most of the original people have moved either to other projects or not particularly that passionate about Nix. In fact, the "best" developer you have who has inherited the whole Nix thing has only really had to deal with all the shit parts of Nix and the system. They are they ones fixing issues, dealing with bugs, etc. All while maintaining 3 stacks, a Nix stack, a Go stack, and a Rust stack.
Eventually that person/team that's annoyed by maintaining the Nix project wins. They want to own that code. They don't want to use Nix any more. They know what's needed, they want to implement it as part of their main Go stack that they are actively working on. They can optimize things for their special case without having to worry about "implementing it the Nix way" or "doing it upstream".
They promise you (the management who is open to the idea, but trying to understand the ROI) feature parity + top 5 feature asks for the initial release. You trust the team enough to let them do what they think is best.
[1]: LLMs are really good at suggesting a solution given an error message. Nix errors bring them to their knees. It's always "Hmmm.... it appears that there is an error in your configuration... have you tried a `git revert`?"