5 ms·

I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types

I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.

rednafi 2y ago
This. From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit. But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane. Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
- cute_boi 2y ago
  This is not because of Rust, but C.
Ar-Curunir 2y ago
[flagged]
- llm_trw 2y ago
  If you don't want to use C perhaps you shouldn't contribute to a 33 year old project written in C?
  - dragonelite 2y ago
    It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project. They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now. If only just a kernel that can run server like application without a gui shell.
    - jenadine 2y ago
      There are many Rust OS mentioned in this thread. (Eg Redox) But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
      - llm_trw 2y ago
        So build a kernel that uses the same API as Linux but in Rust. Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?
        makapuf 2y ago
        Defining a rust API to the linux kernel is one of the endeavours of the Linux kernel project AFAIK
- cogman10 2y ago
  Partially, but it takes two to tango. There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego. I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux. Two people being abrasive to each other with code involved is a disaster.
  - gmokki 2y ago
    Do you mean location as in different subsystem than dma, which is required for all modern devices. Or just location as in stash the files outside the dma directory?
    - cogman10 2y ago
      > Or just location as in stash the files outside the dma directory? This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort). The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer. If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
- FullGarden_S 2y ago
  No? This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C. Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
  - imtringued 2y ago
    I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
    - f1shy 2y ago
      As long as you can directly write registers, you can screw it.
    - FullGarden_S 2y ago
      its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming. Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
efnx 2y ago
Who are these icons?
dralley 2y ago
This is profoundly silly. First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone. C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges. There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution. And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue. In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
- tinco 2y ago
  I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner. He's not a fan of Rust for totally legitimate reasons.
  - throwaway2037 2y ago
    If not Rust, what does he prefer? Zig?
    - tinco 2y ago
      Yeah, mostly Golang and Zig I think.
      - baranul 2y ago
        He is apparently mostly a Golang guy, and has stated he would play around/experiment with Zig. However, this was against the advice of Muratori (who does not like Zig), and suggested Jai (preferred choice) or Odin.
Aurornis 2y ago
My experience with Rust and people who use Rust has actually been great. There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe. Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity. In this specific case, I think this is more about kernel drama than Rust drama.
- imtringued 2y ago
  I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim. You can lie to yourself and say that the same security problems exist in other languages, but that isn't true. When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop. Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
  - ivell 2y ago
    Java also had its share of remote code execution attacks. Security is quite complex domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.
    - gmokki 2y ago
      Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking. Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
chikere232 2y ago
Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in Someone should have hugged them when they were kids
- tw1984 2y ago
  [flagged]
  - chikere232 2y ago
    I haven't seen that as much. The horde of people chasing the hype curve left C behind long ago. When they leave rust, rust will be better off
    - tw1984 2y ago
      I don't care as I don't use rust. I learned and played with it, it is just horrible. I use Python, Golang and C almost everyday for living and fun! Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.
p0nce 2y ago
This is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.

I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.

rednafi 2y ago

This. From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit. But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane. Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.

cute_boi 2y ago
This is not because of Rust, but C.

Ar-Curunir 2y ago

[flagged]

llm_trw 2y ago
If you don't want to use C perhaps you shouldn't contribute to a 33 year old project written in C?
- dragonelite 2y ago
  It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project. They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now. If only just a kernel that can run server like application without a gui shell.
  - jenadine 2y ago
    There are many Rust OS mentioned in this thread. (Eg Redox) But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
    - llm_trw 2y ago
      So build a kernel that uses the same API as Linux but in Rust. Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?
      - makapuf 2y ago
        Defining a rust API to the linux kernel is one of the endeavours of the Linux kernel project AFAIK
cogman10 2y ago
Partially, but it takes two to tango. There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego. I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux. Two people being abrasive to each other with code involved is a disaster.
- gmokki 2y ago
  Do you mean location as in different subsystem than dma, which is required for all modern devices. Or just location as in stash the files outside the dma directory?
  - cogman10 2y ago
    > Or just location as in stash the files outside the dma directory? This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort). The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer. If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
FullGarden_S 2y ago
No? This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C. Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
- imtringued 2y ago
  I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
  - f1shy 2y ago
    As long as you can directly write registers, you can screw it.
  - FullGarden_S 2y ago
    its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming. Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.

efnx 2y ago

Who are these icons?

dralley 2y ago

This is profoundly silly. First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone. C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges. There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution. And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue. In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?

tinco 2y ago
I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner. He's not a fan of Rust for totally legitimate reasons.
- throwaway2037 2y ago
  If not Rust, what does he prefer? Zig?
  - tinco 2y ago
    Yeah, mostly Golang and Zig I think.
    - baranul 2y ago
      He is apparently mostly a Golang guy, and has stated he would play around/experiment with Zig. However, this was against the advice of Muratori (who does not like Zig), and suggested Jai (preferred choice) or Odin.

Aurornis 2y ago

My experience with Rust and people who use Rust has actually been great. There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe. Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity. In this specific case, I think this is more about kernel drama than Rust drama.

imtringued 2y ago
I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim. You can lie to yourself and say that the same security problems exist in other languages, but that isn't true. When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop. Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
- ivell 2y ago
  Java also had its share of remote code execution attacks. Security is quite complex domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.
  - gmokki 2y ago
    Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking. Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.

chikere232 2y ago

Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in Someone should have hugged them when they were kids

tw1984 2y ago
[flagged]
- chikere232 2y ago
  I haven't seen that as much. The horde of people chasing the hype curve left C behind long ago. When they leave rust, rust will be better off
  - tw1984 2y ago
    I don't care as I don't use rust. I learned and played with it, it is just horrible. I use Python, Golang and C almost everyday for living and fun! Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.

p0nce 2y ago

This is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.