Announcement

Collapse
No announcement yet.

Rust Infrastructure Pull Request Submitted For Linux 6.1!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by karolherbst View Post
    literally nobody wanting to get shit done cares about any of that... you can live in your perfect world where everything is perfect, but that doesn't change the fact, that reality is completely different.

    If you know how it's have to be done, then proof the world you are right (spoiler: you won't).

    troll somewhere else
    Hold on so I literally make a point about quality of software and now you're back to "wanting to get shit done" aka outsourced garbage that runs like shit? So thanks for proving my point I guess? My JS example fits even more now. You call it troll, I call it just a mirror that you hate seeing yourself in because you know it's true.

    The thing is, and you're just like them, a lot of people hate it, and I don't mean just programmers, or people who want quality code, but even users. They're sick of it and you're oblivious to it, this is why the software ecosystem is such utter crap nowadays. Having 100 different spins of the same type of app is not a "good thing", THEY ALL SUCK.

    But I mean it makes even more sense now: notice pattern of Rust programmers to rewrite stuff that's already working good? I mean that's what "getting shit done" means in their eyes just like JS "devs": NIH and re-implementing the same shit with even more bloat, using a million frameworks for the simplest of things, because that's all they know how to code. Instead of seeking perfection in one software that has one purpose let's rewrite it so now we have 100 turds instead of one singular app that has no redundant bullshit. But hey you "got shit done" congrats.

    Next time don't even dare to argue against people who talk about software quality if your argument is the typical "getting shit done". It's just an insult to anyone who knows what software quality is. Just like it's an insult to claim Python is much better than C in terms of software quality because "it gets shit done a lot faster". Well if what you wrote was true quality you wouldn't need to "get it done" 100 different times, just once.

    Comment


    • #62
      Originally posted by smitty3268 View Post
      Nouveau. Although I wouldn't be surprised if Weasel knows that already. He frequently gets into these types of arguments and always insists anyone who disagrees with him is an idiot. I don't think it matters what kind of experience the other person involved has.
      What do you mean with disagree, I legit said how simple it is to not use the standard library, because it's just a fucking API and you can use any other library just as well. How is this calling him an idiot or trolling?!?

      He used the standard library as an argument against C, when in C you can even use a C++ library if you know how to. And if he can't, that's his problem, skill issue.

      It literally reminds me of the C++ tards who can't code without boost and think the world revolves around them, and so if you don't use boost you are automatically "inferior". And that's their argument, because they don't have a better one. Like fuck off.

      Comment


      • #63
        Originally posted by anarki2 View Post
        It's kinda ironic that this is exciting news mostly thanks to Apple M1 work being done by Lina.
        You have the order sort of wrong. Rust was proposed a long time ago for the Linux kernel, and has gone through a long process to finally get pulled in. The Apple M1 DRM driver was written in rust only after it was clear that rust support was going to be merged RSN (otherwise it would have had to be written in C).

        One of the goals of accepting rust into the kernel was to lower the overheads of writing and reviewing code, and few would disagree that the DRM subsystem is one where reducing overheads will help going forward.

        Comment


        • #64
          the 0-terminated representation not only makes strlen O(n) as noted previously, but it also means that taking a substring often means performing a heap allocation and copying the contents if you want to be able to use it as a bona fide string (with a final 0), while in Rust you would simply take a slice.
          It's ultimately a tradeoff. While the NUL terminator makes strlen O(n), you can pass certain substrings (namely `s.substr(somePos, strlen(s)-somePos)`) with just the 8-byte pointer itself (in comparison to the 16 bytes required for the representation of a typical slice). Simple iteration requires just one register/variable rather than two. Maybe was a concern on low-register architectures like x86-32.

          Comment


          • #65
            Originally posted by Weasel View Post
            What do you mean with disagree, I legit said how simple it is to not use the standard library, because it's just a fucking API and you can use any other library just as well. How is this calling him an idiot or trolling?!?
            I didn't make any kind of judgement on the arguments in any of the comments here. I simply made my opinion known that I doubted you would care who you were talking to and would consider their experience pointless, because you tend to always highly value your own take on things and assume everyone else is wrong unless they agree with you.

            Am I wrong about that? Now that you for sure know who Karol Herbst is, does that change anything? Judging from one of the replies above, it seems not.
            Last edited by smitty3268; 04 October 2022, 09:37 PM.

            Comment


            • #66
              Originally posted by smitty3268 View Post
              I didn't make any kind of judgement on the arguments in any of the comments here. I simply made my opinion known that I doubted you would care who you were talking to and would consider their experience pointless, because you tend to always highly value your own take on things and assume everyone else is wrong unless they agree with you.

              Am I wrong about that? Now that you for sure know who Karol Herbst is, does that change anything? Judging from one of the replies above, it seems not.
              You're mostly right. Although I don't tend to consider people wrong unless it's a fact-based argument. If it's just about opinions, I just state my (differing) viewpoint. For example oiaohm is almost always wrong, and I make no qualms about telling it.

              In this case it's a mix. It's definitely true that C doesn't enforce NUL terminated strings, so that's where he was completely wrong. You can even compile C code without the standard library (-nostdlib) and it works perfectly fine. You can still use the standard library if you treat it as just another normal library/API, too. So here he was wrong. Not every standard library is statically linked like Rust's.

              But his dependence on standard libraries is just dumb to me. I will never understand such people unless they literally want to write portable code only, but portable code will always perform worse than target-specific code, which is another fact I outlined about standard libraries. Another one he got mad at and pulled a logical fallacy.

              Note that target-specific code only needs to be target-specific in a few areas, so it's not like you need to rewrite the entire huge project. For example Firefox has target-specific code in many areas (imagine if it used GTK on Windows, yuck!), but it doesn't mean they rewrote the entire browser for it.

              Comment


              • #67
                Originally posted by Weasel View Post
                notice pattern of Rust programmers to rewrite stuff that's already working good?
                Yes, and it's generally excellent. They're rethinking utilities like grep, du, find, using rust's excellent CLI support crates for consistent option handling, readline, progress indicators,.etc. The good replacements are generally fast and a joy to use; ripgrep is fantastic. My problem is the old tools are baked into my muscle memory.

                You're free to continue on with the same crummy commands we've had for 20 years.

                Comment


                • #68
                  Originally posted by skierpage View Post
                  Yes, and it's generally excellent. They're rethinking utilities like grep, du, find, using rust's excellent CLI support crates for consistent option handling, readline, progress indicators,.etc. The good replacements are generally fast and a joy to use; ripgrep is fantastic. My problem is the old tools are baked into my muscle memory.

                  You're free to continue on with the same crummy commands we've had for 20 years.
                  Some of the rewrites also end up being faster because they are rewritten with parallelism in mind, which either originally wasn't done or it was done sparingly due to how easy it is to shoot yourself in the foot with it in C.

                  Comment

                  Working...
                  X