6 ms·

Why is that soc guy so angry and rude about it?

orlp 1y ago
I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.
- GoblinSlayer 1y ago
  The library addresses your use case: provides location to store configs. You're asking for your personal feature.
dclowd9901 1y ago
[flagged]
- mtndew4brkfst 1y ago
  It's unkind to publicly speculate on this in this particular way, IMO.
  - dclowd9901 1y ago
    Kindness is reciprocal, IMO. But I will concede speculation is unproductive.
x3n0ph3n3 1y ago
Certainly doesn't make me want to become a Rust contributors.
- dagmx 1y ago
  dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.
  - anttiharju 1y ago
    I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this. From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. Like apparently serde the library is responsible for most of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app. Happy to be corrected on my statements, not 100% on anything. edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680 https://news.ycombinator.com/item?id=45022680
    - trissylegs 1y ago
      It doesn't have very large standard library. It's just running on a different philosophy on not making the Standard Library "Batteries included". But I find you get less dependencies than npm. Not so many tiny left-pad like microlibraries. The main cost of compile times is Generics. Rust generics use "Monomorphization" which generate different binary code for every use of a generic type. serde leverages generics everywhere and it generates the serialization code for every type you make serializable. So when you use `serde_json::to_string(MyType::new())` it follows calls a code path just for serializing MyType to a json string. The upshot: It's incredibly fast, there's a lot of inlining and other compiler optimisations that can used because of it. No runtime reflection (Which is how Go does a lot of it). The downsides: Takes a long time to compile cause of all the extra it's generating. Also can inflate binary sizes at bit. Other languages like Go mostly use run time reflection for Json. Rust doesn't have much runtime reflection so doing it here wouldn't be possible
    - johnisgood 1y ago
      > From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. My experiences as well. Try to "cargo build" any projects, and you will immediately see the node-esque problems. It does not fill me with hope.
deleted 1y ago
[deleted]
notachatbot123 1y ago
Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out. It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version. But stop pestering maintainers with demands.
- Aurornis 1y ago
  > But stop pestering maintainers with demands. I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links. This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical. The refrain of “just fork it!” is a cop-out. Forking software so you can maintain a fork forever isn’t a trivial decision. It’s not helpful to the community to have to choose between a lot of different forks that have minor differences. I agree that open source maintainers don’t owe anyone anything, but I think this mentality is being taken too far when with the “maintainer is always right” mentality combined with blaming the issue starter for the maintainer’s behavior.
  - notachatbot123 1y ago
    I used pestering for OP's "I and others have brought this up (...) but they refuse to see it this way (...). It's very frustrating." Suggest it once, discuss it, get refused, move on. Instead there are tens of comments and above is a complaint about an additional ticket for the same issue. I am not saying that maintainers are necessarily right, but they are in their right to build their project how they like it. It is a bad pressure and force if people continue to ask for things that a maintainer has already ruled out. What's the goal otherwise, caving in due to pressure and stress?
  - whatevaa 1y ago
    Then maintainer will stop maintaining and you will have to fork anyway. So it's lose-lose for everybody. Fork and move on with your life.

orlp 1y ago

I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.

GoblinSlayer 1y ago
The library addresses your use case: provides location to store configs. You're asking for your personal feature.

dclowd9901 1y ago

[flagged]

mtndew4brkfst 1y ago
It's unkind to publicly speculate on this in this particular way, IMO.
- dclowd9901 1y ago
  Kindness is reciprocal, IMO. But I will concede speculation is unproductive.

x3n0ph3n3 1y ago

Certainly doesn't make me want to become a Rust contributors.

dagmx 1y ago
dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.
- anttiharju 1y ago
  I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this. From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. Like apparently serde the library is responsible for most of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app. Happy to be corrected on my statements, not 100% on anything. edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680 https://news.ycombinator.com/item?id=45022680
  - trissylegs 1y ago
    It doesn't have very large standard library. It's just running on a different philosophy on not making the Standard Library "Batteries included". But I find you get less dependencies than npm. Not so many tiny left-pad like microlibraries. The main cost of compile times is Generics. Rust generics use "Monomorphization" which generate different binary code for every use of a generic type. serde leverages generics everywhere and it generates the serialization code for every type you make serializable. So when you use `serde_json::to_string(MyType::new())` it follows calls a code path just for serializing MyType to a json string. The upshot: It's incredibly fast, there's a lot of inlining and other compiler optimisations that can used because of it. No runtime reflection (Which is how Go does a lot of it). The downsides: Takes a long time to compile cause of all the extra it's generating. Also can inflate binary sizes at bit. Other languages like Go mostly use run time reflection for Json. Rust doesn't have much runtime reflection so doing it here wouldn't be possible
  - johnisgood 1y ago
    > From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. My experiences as well. Try to "cargo build" any projects, and you will immediately see the node-esque problems. It does not fill me with hope.

deleted 1y ago

[deleted]

notachatbot123 1y ago

Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out. It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version. But stop pestering maintainers with demands.

Aurornis 1y ago
> But stop pestering maintainers with demands. I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links. This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical. The refrain of “just fork it!” is a cop-out. Forking software so you can maintain a fork forever isn’t a trivial decision. It’s not helpful to the community to have to choose between a lot of different forks that have minor differences. I agree that open source maintainers don’t owe anyone anything, but I think this mentality is being taken too far when with the “maintainer is always right” mentality combined with blaming the issue starter for the maintainer’s behavior.
- notachatbot123 1y ago
  I used pestering for OP's "I and others have brought this up (...) but they refuse to see it this way (...). It's very frustrating." Suggest it once, discuss it, get refused, move on. Instead there are tens of comments and above is a complaint about an additional ticket for the same issue. I am not saying that maintainers are necessarily right, but they are in their right to build their project how they like it. It is a bad pressure and force if people continue to ask for things that a maintainer has already ruled out. What's the goal otherwise, caving in due to pressure and stress?
- whatevaa 1y ago
  Then maintainer will stop maintaining and you will have to fork anyway. So it's lose-lose for everybody. Fork and move on with your life.