Rust lobbyists winning

  • TheDoctor [they/them]
    ·
    19 days ago

    They’re currently exploring using AI to mass translate software from C to Rust, which will be hilarious if it doesn’t cause Armageddon

    • urmums401k [she/her, they/them]
      ·
      19 days ago

      I'm actually in favor of this. It's a really good idea, and I hope the state uses it for all the important databases they're gonna use to put us in the camps.

      Please dont be a hater. Comrade AI might just save lives here.

    • blame [they/them]
      ·
      19 days ago

      that seems like it wouldn't work very well except maybe for small programs. the kinds of bugs they're trying to catch and prevent here may need substantial changes to the program's design in order to prevent. Like the borrow checker literally does not exist in C and it is not a thing people thought about when writing asynchronous C code. Maybe the AI will take a shortcut and write a bunch of unsafe rust code, but in that case what's the point?

    • bobs_guns@lemmygrad.ml
      ·
      19 days ago

      This won't work completely. Large language models usually fail thoroughly when writing Rust code as there's not as much training data.

  • Owl [he/him]
    ·
    19 days ago

    Which do you think happened?

    • Honest appraisal of C++ security problems

    • They figured out some security hole in C++ programs that makes them even worse than we thought

    • Some contractor bribed them to say this so that they can get contracts porting stuff to Rust

    • Some contractor dug up new legitimate security holes in C++ programs so they can convince the FBI to say this so they can get contracts porting stuff to Rust

    • High ranking FBI officials are rust fanboys

    I think contractor bribes, but I think that last two are fun.

    • blobjim [he/him]
      ·
      19 days ago

      It's just the obvious thing. C and C++ don't have safeguards against dangerous programming mistakes. Programming languages exist that do. There are to this day still software vulnerabilities being caused by subtly incorrect code that C and C++ require being treated as legitimate.

      • brainw0rms [they/them]
        ·
        19 days ago

        C and C++ don't have safeguards against dangerous programming mistakes.

        This is not really true for modern C++... and if you're talking about code bases that use an ancient dialect of C++ where it might be true, the fantasy of even having the option of porting to Rust is actually pretty laughable. C will continue to be necessary for many critical things because there simply isn't sufficient compiler support coverage for Rust to take the throne.

        • sexual_tomato@lemmy.dbzer0.com
          ·
          edit-2
          19 days ago

          The difference here is that it takes discipline and training to use only those parts of C++. That requires humans in the loop to enforce those decisions. Humans are fallible.

          If you make it impossible at the language level then there's nothing to train. You just can't do the thing unintentionally.

          And they didn't specify Rust; the aerospace industry has been using Ada for decades when it comes to mission critical stuff. Ada's compiler has long had a similar notoriety to rust's regarding the difficulty curve.

          • smpl@discuss.tchncs.de
            ·
            19 days ago

            My guess would also be that most enterprises prefer Ada over Rust, because Rust lack standardisation. Sometimes you need to do unsafe things though and your billion dollar rocket explode.

  • OprahsedCreature@lemmy.ml
    ·
    19 days ago

    Am I wrong or is this a strong point in favor of c/c++? I'd generally want to do whatever the opposite is of what the FBI would like me to do.

    • GaveUp [she/her]
      hexagon
      ·
      edit-2
      19 days ago

      "critical software" here refers to weapons systems, spying systems, government surveillance systems, cyberwarfare software, etc.

      Do you work on critical software

    • blame [they/them]
      ·
      19 days ago

      their reasoning is that rust (and perhaps others) that can be used in place of c or c++ have stronger compile time memory and thread safety checking which are two major sources of bugs and exploit vectors. So it's not like they're infiltrating the language in this case the way they would with crypto.

    • urmums401k [she/her, they/them]
      ·
      edit-2
      19 days ago

      Right but AI translating of all government code is good. This is what you want, especially if shit goes down. Dont tell your enemy to stop pouring the kool aid.

    • Owl [he/him]
      ·
      19 days ago

      Nah, that kind of reasoning is like "nazis think people should get armed, so we shouldn't."

    • bobs_guns@lemmygrad.ml
      ·
      19 days ago

      It's not really a strong point. C++ has its place for graphics programming and gamedev and C has its place for embedded, but Rust would be a better choice for something like a cryptography app to help revolutionaries communicate for example.

    • toys_are_back_in_town [comrade/them, she/her]
      ·
      19 days ago

      I hope you're joking. This mindset has had terrible consequences, such macho bullshit needs to go.

      The Zionazis will find your mistakes before you do. So have the computer check your work as much as possible.

      • kleeon [he/him, he/him]
        ·
        19 days ago

        I am mostly joking but rust is quite annoying and is only useful in very specific circumstances. I'm not against encouraging people to use better designed languages than C though

        • toys_are_back_in_town [comrade/them, she/her]
          ·
          19 days ago

          rust is quite annoying

          skill issue

          and is only useful in very specific circumstances

          huh? about the only place I can't use rust is on microcontrollers, and it's kind of a pain in the dick on mobile (just use kotlin lol)

          • kleeon [he/him, he/him]
            ·
            19 days ago

            skill issue

            Most rust programmers don't know how to implement a linked list

            • toys_are_back_in_town [comrade/them, she/her]
              ·
              19 days ago

              I'm not sure if you're making a real point or if it's something you heard is complicated but never looked into why. You almost never actually write a linked list. There are usually way easier ways to have a potentially infinite list, but more often you will write your code to operate on blocks of arrays of known size for performance reasons (cache locality, etc) or safety reasons (memory exhaustion, etc), or the linked list is hidden away in a queue implementation (which again you usually want to make bounded).

              Most C++ programmers don't actually understand lifetimes or even basic memory safety.

              Most programmers don't know when they should be using a linked list or something more cache-friendly.

              Most software is really bad.

              If I can get away with it, I'll bang something out in Python or whatever I'm required to do something in for the task at hand, and I'll absolutely know 10 ways my program can break, but if I need speed AND reliability, it necessarily takes effort from me, the programmer, to tell the computer exactly how it has to go down. And then Rust usually lets me say what I want to say.

              • neo [he/him]
                ·
                18 days ago

                Most C++ programmers don't actually understand lifetimes or even basic memory safety.

                Fingers crossed I get this job I'm applying for where they actually care about this.

                • toys_are_back_in_town [comrade/them, she/her]
                  ·
                  edit-2
                  18 days ago

                  oh okay you're actually stupid

                  wow

                  I am blown away that even in a socialist space people like you are obsessed with employment, and not with whether your program actually functions.

                    • toys_are_back_in_town [comrade/them, she/her]
                      ·
                      18 days ago

                      I interpreted your comment as being dismissive of understanding basic memory safety because no jobs care about this.

                      I thought it ridiculous that people don't care that their programs explode. I guess it changes your mindset when your service going down isn't a matter of costing the company money, but affecting real people.

                      But maybe you weren't being sarcastic?

                      • neo [he/him]
                        ·
                        18 days ago

                        I was being serious. I offhandedly expressed some excitement, in a comment I forgot I even wrote, about interviewing at a place that writes modern c++. Which, if you don't know, c++11 and especially beyond has features to manage lifetimes, ownership, memory, and other important things just as Rust does (but it's still C++, so of course it has all the baggage C++ must carry and a compiler that doesn't enforce any of this).

                        But you rushed at the opportunity to be a complete ass about it and insult me for no reason. Presumably you also dismissively assumed I've never written Rust. Or that in 2024 the Rust jobs are so overflowing that I can just take my pick at one at my own leisure. As if my first preference is to write software in a language that still requires forward declarations.

                        Yeah. You had such a good point, though. I really would rather not have an income in favor of writing perfectly memory safe software that nobody uses. Surely you have advice on that?

                        • toys_are_back_in_town [comrade/them, she/her]
                          ·
                          18 days ago

                          Sorry about the friendly fire then, I guess. You seem to realize that in C++ you still have to think about lifetimes, only the compiler doesn't really hold your hand. I thought you were the ASSHOLE who dismissively declared that Rust programmers don't know how to write a linked list, without realizing that the problem is that C++ programmers usually don't know how to write C++ either. And that's why everything is on fire.

                          But you had to make more presumptions about my assumptions, and throw in a "nobody uses" because you genuinely have no idea how much my software is used, lol. So long as it keeps humming along you'll never have to.

          • TrashGoblin [he/him, they/them]
            ·
            19 days ago

            Just because you can, doesn't mean you should. For application code, it's almost always better to use a language with garbage collection, in order to get memory safety without undue ceremony. Yes, some gc-ed languages are slow (Python, Ruby), but others are quite fast (JVM, .NET, Common Lisp, Haskell).

        • someone [comrade/them, they/them]
          ·
          19 days ago

          If you're looking to write the types of server daemons often written in C, Go is another good choice. It's very C-like in its syntax. It has a lot of the same safety features Rust has but isn't nearly as complex to learn. It also has a huge standard library, so you rarely need to rely on third-party code.

          Go isn't too suitable for drivers or kernels or other kinds of system software though. Rust is definitely a better choice for those.

  • kittin [he/him]
    ·
    19 days ago

    I really want Go but without a garbage collector is that too much to ask

      • kittin [he/him]
        ·
        edit-2
        19 days ago

        My only real criticisms of rust are aesthetical. I never liked how C++ is full of macros and :: and <> and rust inherits that a bit.

        I use Go because of the work I do right now, which is deep in Kubernetes and APIs for which Go is just more convenient. Protobuf and K8S are of course supported by rust and many other languages as well, but in Go it’s simply easy… Go was designed from the bottom up to write APIs basically so it’s good at that. And most, almost all, of the K8S ecosystem uses Go which means I’d need a good reason not to use Go for that since standardization, interoperability, and ecosystem are key concerns.

        You can use rust for this too, for sure no problem. But with Go you’re doing all of that pretty much out of the box.

        The Go ecosystem in general is a little bit stronger due to higher adoption, although I wouldn't really call that a weakness of rust.

        And finally less people use Rust which is another consideration for long term maintenance concerns, but to be fair Go adoption is also low.

        I’m never an evangelist for any language. Well, if I could simply write everything in typescript I would to be honest because I think it’s just swell but obviously its not for this use case, and the above are the reasons why I use Go and get my teams to use Go for the use case of services, Kubernetes controllers, and since we want to use Go for those things we then also use Go for other random things like CLIs etc just because it makes sense to limit tech stack sprawl.

    • toys_are_back_in_town [comrade/them, she/her]
      ·
      19 days ago

      also, separate comment, what are you generally building? if you're writing Go because it's network code, you might want to look into Elixir. It's GC but the behavior of BEAM is more soft-RT friendly due to its history in telephony, you might be more at home there

    • machinya [it/its, fae/faer]
      ·
      18 days ago

      i have not tried it myself but have you taken a look into zig? it looks alot like go but is lower level. i have heard good things about it and it looks nice. of course the ecosystem is quite limited since it's a quite new language

      • kittin [he/him]
        ·
        17 days ago

        I haven’t checked it out at. Thanks for the suggestion :), it might be the dream

  • collapse_already@lemmy.ml
    ·
    19 days ago

    Is CERT code included? I think there is a group working on a secure version of C++ as well. I'm not convinced that shifting experienced programmers to mew less familiar syntax will improve software quality. Improving the language rather than changing to another might be a better approach.

    I guess assembly also ought to be avoided since all of the power/flaws of C are extant in it as well.