On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).

On the other hand, when weighing one’s feelings against the common good, I guess it’s not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?

  • mipadaitu@lemmy.world
    link
    fedilink
    English
    arrow-up
    74
    arrow-down
    3
    ·
    9 months ago

    Depends on if you’re coding for critical infrastructure (i.e. - electrical grid), or writing a high performance video game that can run on older hardware.

    We should absolutely have specific licenses like Civil Engineers do for computer infrastructure that is required for any software written for specific purposes. It would be a nightmare to implement, but at some point, it’s going to be needed.

    • SorteKanin@feddit.dk
      link
      fedilink
      arrow-up
      35
      arrow-down
      12
      ·
      9 months ago

      writing a high performance video game that can run on older hardware

      Unless it’s some really exotic platform, I’d honestly still say no. Rust has shown that memory safety and performance doesn’t have to be a tradeoff. You can have both.

      But sure, if whatever you’re targeting doesn’t have a Rust compiler, then of course you have no choice. But those are extremely rare cases these days I’d say.

      • themusicman@lemmy.world
        link
        fedilink
        arrow-up
        27
        arrow-down
        6
        ·
        9 months ago

        There’s always a trade-off. In rust’s case, it’s slow compile times and comparatively slower prototyping. I still make games in rust, but pretending there’s no trade-off involved is wishful thinking

        • Lmaydev@programming.dev
          link
          fedilink
          arrow-up
          30
          arrow-down
          1
          ·
          9 months ago

          They mean a trade off in the resulting application. Compile times mean nothing to the end user.

          • Dave.@aussie.zone
            link
            fedilink
            arrow-up
            14
            arrow-down
            3
            ·
            9 months ago

            That may be true but if the language is tough to develop with, then those users won’t get a product made with that language, they’ll get a product made with whatever language is easier / more expedient for the developer. Developer time is money, after all.

            • Lmaydev@programming.dev
              link
              fedilink
              arrow-up
              3
              ·
              edit-2
              9 months ago

              You’d be better just using a managed languages in many cases.

              With tiered jit and careful use of garbage allocations they can actually be the same or faster.

      • MareOfNights@discuss.tchncs.de
        link
        fedilink
        arrow-up
        6
        arrow-down
        5
        ·
        9 months ago

        Can we stop pretending Rust doesn’t take performance trade-offs? Of course if you compare it one to one its roughly the same, since it’s compiled. But Optimizing memory for cache hits becomes a lot more difficult in Rust, to the point where you have to use unsafe. And unsafe Rust has more undefined behavior than C. In my opinion C is more safe than unsafe Rust.

        If you want normal performance its a good Language, but once you need to Optimize memory, which is usually the bottleneck, You are out of luck.

      • cm0002@lemmy.world
        link
        fedilink
        arrow-up
        9
        arrow-down
        23
        ·
        edit-2
        9 months ago

        I don’t even think we really need to eek out every MHz or clock cycle of performance these days unless your shipping code for a space vehicle or something (But that’s an entirely different beast)

        We’ve got embedded devices shipping with 1GHz+ processors now

        It’s just time to move on from C/C++, but some people just can’t seem to let go.

        • Cirk2@programming.dev
          link
          fedilink
          arrow-up
          21
          ·
          9 months ago

          That is the mindset that gives us text editors using 100% cpu to blink a cursor because their css triggers a bug in the web browser they ship to render the text editor.

          You can be memory save without shipping a whole browser, but disregarding power and memory efficiency will just make performance gained by hardware evaporate in overhead.

        • pycorax@lemmy.world
          link
          fedilink
          arrow-up
          13
          ·
          9 months ago

          Battery life is a reason. I’ve had clients come to me complaining their solution from another vendor didn’t last very long. Turns out it was running Java on an embedded device.

          • Akisamb@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            9 months ago

            Why would java have an impact on battery performance ? Pretty much all credit cards run java for their encryption algorithms, and they need pretty much no power to run.

            • pycorax@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              9 months ago

              The JVM isn’t free. It was a simple data collection device that interfaces with a sensor which ideally doesn’t need maintenance as long as possible. Something light written in C is more than enough.

            • Croquette@sh.itjust.works
              link
              fedilink
              arrow-up
              2
              ·
              9 months ago

              There are orders of magnitude in what is considered low current. I’ve worked on a product that was guaranteed 2 years of lifetime for 3 AA batteries.

        • Croquette@sh.itjust.works
          link
          fedilink
          arrow-up
          10
          ·
          9 months ago

          Because there is still market for small mcus. A 1GHz processor is a lot more expensive than a 32 bits 75MHz. If you produce even a low number of units, the price difference can be huge.

          • frezik@midwest.social
            link
            fedilink
            arrow-up
            1
            ·
            9 months ago

            A lot of those mcus don’t need to run particularly complex programs. Many of them don’t do anything more complicated than reading the status of a pin and using that to activate another pin. 75MHz with a Rust program is more than enough.

            For that matter, when Python was first released, the Intel Pentium wasn’t even out yet. People made it work. Micropython could handle the above just fine provided the polling rate didn’t need to be that high.

            It’ll all depend on the application, of course, but a huge number of mcu programs could easily be Rust. The performance hit is not that big. The code size on lower end mcus is also going to be naturally limited by their flash space, so even the compiler speed isn’t going to be a big hit.

            One thing is that the last time I tried using Rust on an esp32, the toolchain was still in its infancy and didn’t work very well. Looks like Go has been ported in, as well, but it doesn’t support wifi or bluetooth on the esp32. Or even i2c or pwm.

            • Croquette@sh.itjust.works
              link
              fedilink
              arrow-up
              3
              ·
              edit-2
              9 months ago

              I haven’t seen a test on the difference between rust and c, but your last point is the biggest caveat for rust.

              If you have been running the same toolchain on multiple products, changing the language means a productivity loss because the devs need to learn the ins and outs of the new language, and if the toolchain is buggy, then it is another productivity loss.

              I’m always eager to try out new stuff in products I design, but the incertitude and productivity loss is a no go because I can just spin a barebone code that works in half a day.

              Until the tool chain is mature, C will still exist.

        • suy@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          9 months ago

          It’s just time to move on from C/C++, but some people just can’t seem to let go.

          The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) “Almost. We have the blocks, bring your own glue” and “The roots aren’t deep but the seeds are planted”. I’ve seen the progress in Bevy and Slint, but it’s still the same, those websites don’t change, and my situation WRT to making a Rust project for fun or work it’s the same.

          I’ll be happy to start doing Rust projects whenever I get the chance (which will be when it’s a sufficient tool for my use cases). But I’m tired of smoke sellers.

          • calcopiritus@lemmy.world
            link
            fedilink
            arrow-up
            2
            arrow-down
            4
            ·
            9 months ago

            Have you actually tried making a GUI or a game? I don’t think you can summarize the state of the whole ecosystem in a sentence that doesn’t change in years. I’ve made perfectly functional GUIs with iced, and imgui. Haven’t tried slint yet.

            Godot is a very popular game engine and it’s written in rust, so you probably can use it in rust.

            • suy@programming.dev
              link
              fedilink
              arrow-up
              2
              ·
              9 months ago

              I’ve wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it’s rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it’s just that so far, the time has not been right.

              Note that my point is not that it’s unusable for everyone. Just that it’s false that “some people just can’t seem to let [C or C++] go”, as the previous comment said. I can’t let go something that works well for something that doesn’t, given the projects that I have to work on.

      • fidodo@lemmy.world
        link
        fedilink
        English
        arrow-up
        17
        arrow-down
        1
        ·
        9 months ago

        Oh, well of course that’s fine. The government is talking about software that is used for important systems. No hacker will even know about your personal side project.

  • mox@lemmy.sdf.org
    link
    fedilink
    arrow-up
    53
    ·
    9 months ago

    I’m just glad to see the White House listening to people who understand technology for a change.

    • jkrtn@lemmy.ml
      link
      fedilink
      arrow-up
      23
      ·
      9 months ago

      We need legislators who aren’t all literally older than cryptography. If they weren’t bought and paid for by billionaires that would be nice too.

        • demesisx@infosec.pub
          link
          fedilink
          English
          arrow-up
          21
          arrow-down
          2
          ·
          edit-2
          9 months ago

          Don’t blame the victims for a sham of a democracy. First-past-the-post (FPTP) is there to prevent anything outside of a two party system where primaries are filled with (fully allowed) election fraud and cheating.

          “we could have voluntarily decided that, Look, we’re gonna go into back rooms like they used to and smoke cigars and pick the candidate that way. That’s not the way it was done. But they could have. And that would have also been their right.” - DNC Lawyer

          • parens@programming.dev
            link
            fedilink
            arrow-up
            5
            ·
            9 months ago

            FPTP does destroy a lot, I’ll give you that, but municipal and regional elections have miserable turn-outs too and they have much more potential for perceptible change than state or national change.

            In the USA things have to get way worse than they are now before they get better. A very very large percentage of voters would have to be fed up with FPTP to force change in that area. Also, they would have to be educated enough to understand that FPTP is a problem.

            • demesisx@infosec.pub
              link
              fedilink
              English
              arrow-up
              12
              ·
              edit-2
              9 months ago

              For one, FPTP doesn’t get enough credit for just how nefarious it is. And let me be clear: I am speaking of the presidential election specifically, though I’m sure this applies to many aspects of this “democracy” including state elections, etc that you mentioned.

              Instead, the overarching establishment narrative likes to point the finger at the electoral college (which also quite heavily biases the power of votes toward voters in less populous areas and states).

              Since the established oligarchs (who own the news outlets) tend to control information delivery in this country, how would you break through that wall? Would you engage in peaceful protest (or self immolation)? Well, they’ve got a playbook for that too. They will discredit you and make you seem unhinged. For proof of that, look at the way they’re delegitimizing the brave, selfless active duty Air Force member who engaged in peaceful protest by self immolation outside of the Israeli embassy against the Gaza war for just how easy it is. Most news watching voters probably already think he was crazy. It didn’t quite have the power that that act had during, say, the Vietnam war.


              Since you’re here, I’m guessing you’re a software engineer. Do me a favor: Model the real world dynamics of a US presidential election using domain driven design, making sure to accurately represent the two objectively unfair stages:

              Rule #1: All candidates must pass stage 1 to be eligible for stage 2.

              In stage 1, feel free to cheat, commit fraud, and engage in any strategy you need to prevent anyone but the owners of the party’s preferred candidates from winning. After all, your party is a private organization that can engage in whatever unfair tactic they deem necessary.

              In stage 2, (if you’re paying attention, you ALREADY have irreparably biased the possible outcomes by cheating in stage 1) because of FPTP, you can now simply choose between only two of the MANY, MANY parties.

              If you designed a system like that as a software engineer, your colleagues would be at your throat about how flawed that design was. However, here in the US, that’s just the design of our dEMoCrACy oF tHa gReATeSt cOuNTry iN tHa wErLD! 🥴

              Edit: That “much worse” statement seems to come from a place of privilege. Don’t forget that. RIGHT NOW, more people are homeless and destitute than any other time in MY LIFE (I was born in the late 70’s). And most people literally have no say in whether or not their tax money is being used to genocide Muslims overseas to make room for a puppet government. Remember: You’re an anti-Semite if you oppose genocide.

              • parens@programming.dev
                link
                fedilink
                arrow-up
                2
                ·
                9 months ago

                Remember: You’re an anti-Semite if you oppose genocide.

                Clearly. Good people can’t do bad things.

        • jkrtn@lemmy.ml
          link
          fedilink
          arrow-up
          8
          ·
          9 months ago

          It requires score voting so that, even if heavily gerrymandered, one can still meaningfully express a preference without throwing one’s ballot in the garbage.

          • Hacksaw@lemmy.ca
            link
            fedilink
            arrow-up
            5
            arrow-down
            2
            ·
            9 months ago

            It’s never throwing your ballot in the garbage though. I used to think the same way, but every vote on the left, even if for the lesser evil, even if they lose, moves the conversation to the left. When we all stay home you get maga nutjobs stealing the show running unchecked.

            Last thing is that gerrymandered states are the EASIEST to upset by increasing voter turnout. To gerrymander effectively you have to put your opponent in dense areas they’ll win by a large margin, then spread your side so that you barely win the rest of the districts. That means that a 5% increase in votes on the left can take you from a loss to a nearly complete victory in a gerrymandered state.

            Vote splitting on the other hand is a trickier beast, but in the end if all the left votes go to a moderate then that gives the left a lot of leverage because if the moderate candidate doesn’t bend to the left then they’ll lose the next election.

            Always vote.

            • jkrtn@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              9 months ago

              You are correct. I hope nobody thought I am against voting. Everyone needs to vote.

              • fruitycoder@sh.itjust.works
                link
                fedilink
                arrow-up
                2
                ·
                9 months ago

                Mostly just saying it outload, I know I fall into the trap myself and just need reminding “perfect is the enemy of good” sometimes.

    • fruitycoder@sh.itjust.works
      link
      fedilink
      arrow-up
      7
      ·
      9 months ago

      This admin honestly has been consistently doing so IMHO. Having read a memo that felt like a crock of shit yet, except for maybe the unfunded nature of some of the demands.

    • Oliver Lowe@lemmy.sdf.org
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      I feel this is a bit of a moot point from the White House. Memory-safe languages have been around for decades. I feel like the amount of C/C++ out there isn’t so much that people think having dangerous stuff around is good, but more that nobody really wants to pay to change it.

  • TechNom (nobody)@programming.dev
    link
    fedilink
    English
    arrow-up
    35
    ·
    9 months ago

    they don’t feel like your fighting the language

    I really understand what you mean wrt Rust. I really do - I was there once. But it’s a phase you grow out of. Not just that - the parts you fight now will eventually become your ally.

    and let me feel sort of creative in the way I do things

    I had the same experience with C/C++. But as the design grows, you start hitting memory-safety bugs that are difficult to avoid while coding - even after you learn how those bugs arise in the first place. Just a lapse of concentration is enough to introduce such a bug (leaks, use-after-free, deadlocks, races, etc). I’ve heard that C++ got a bit better after the introduction of smart pointers and other safety features. But, it comes nowhere near the peace of mind you get with garbage collected languages.

    That’s where Rust’s borrow checker and other safety measures kick in. The friction disappears when you acquire system knowledge - concepts of stack, heap, data segment, aliasing, ownership, mutation, etc. These knowledge are essential for C/C++ too. But the difference here is that Rust will actually tell you if you made a mistake. You don’t get that with C/C++. The ultimate result is that when a Rust program compiles successfully, it almost always works as you expect it to (barring logical errors). You spend significantly less time debugging or worrying about your program misbehaving at runtime.

    The ‘friction’ in Rust also helps in another way. Sometimes, you genuinely need to find a way out when the compiler complains. That happens when the language is too restrictive and incapable of doing what you need. You use things like unsafe, Rc and Refcell for that. However, most of the time, you can work around the problem that the compiler is indicating. In my experience, such ‘workarounds’ are actually redesigns or refactors that improve the structure of your code. I find myself designing the code best when I’m using Rust.

    • crimsonpoodle@pawb.socialOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      9 months ago

      I do really like the error system in rust for its descriptions. I guess the difficulty for me, which maybe will go away after writing more rust, is that my intuition for what is efficient and what isn’t totally breaks down.

      I find myself passing copies of values around and things like that, it might be that the compiler just takes care of that, or that I just don’t know how to do it well but that’s often the point of friction for me.

      Totally agree on the refactor though, most of the time it doesn’t even take that much time since you know the skeleton of what you want at that point!

      • TechNom (nobody)@programming.dev
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        9 months ago

        I find myself passing copies of values around and things like that, it might be that the compiler just takes care of that,

        Rust prefers explicitness over magic. So it does what you tell it and doesn’t just take care of that.

        If you’re copying a lot of values around (I.e cloning. Not moving or borrowing), then you’re definitely doing it inefficiently. But you don’t have to worry too much about that. If there are too many difficulties in borrowing, it may be because those borrows are problematic with respect to memory safety. In such cases, sacrificing performance through cloning may be an acceptable compromise to preserve memory safety. In the end, you end up with the right balance of performance (through borrowing) and safety (through cloning). That balance is hard to achieve in C/C++ (lacking in safety) or in GC languages (lacking in performance).

        If that’s the friction you’re facing in Rust, then I would say that you’re already in a good position and you’re just trying too hard.

  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    36
    arrow-down
    12
    ·
    edit-2
    9 months ago

    Leaders in Industry Support White House Call to Address Root Cause of Many of the Worst Cyber Attacks

    And it’s called C/C++. It’s gotten so bad that even the friggin’ white house has to make a press release about it. Think about it, the place where that majority barely even understand the difference between a file browser and a web browser is telling you to stop using C/C++. Hell, even the creator and maintainers of the language don’t know how to make it memory safe. If that isn’t a wake up call, then nothing ever will be.

    And this isn’t the first call! The IEEE also says more clearly: GTFO C/C++.

    If you want memory-safe, don’t write C/C++. Trying to get that shit memory-safe is a hassle and a half. You’re better off learning a language that isn’t full of foot-guns, gotchas, and undefined behavior.

    CC BY-NC-SA 4.0

    • Feathercrown@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      9 months ago

      You’re better off learning a language that isn’t full of foot-guns, gotchas, and undefined behavior.

      As a JS developer, seeing this quote about C/C++ for a change gives me unbelievable levels of schadenfreude

    • abhibeckert@lemmy.world
      link
      fedilink
      arrow-up
      20
      arrow-down
      10
      ·
      9 months ago

      If you want memory-safe, don’t write C/C++.

      Fixed that for you. There’s no situation where you want buffer overruns.

      • cm0002@lemmy.world
        link
        fedilink
        arrow-up
        22
        arrow-down
        1
        ·
        9 months ago

        There’s no situation where you want buffer overruns.

        I want buffer overruns in my game consoles for jailbreaking purposes lmfaoooooo

      • evranch@lemmy.ca
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        edit-2
        9 months ago

        If you don’t want memory-safe buffer overruns, don’t write C/C++.

        Fixed further?

        It’s perfectly possible to write C++ code that won’t fall prey to buffer overruns. C is a lot harder. However yes it’s far from memory safe, you can still do stupid things with pointers and freed memory if you want to.

        I’ll admit as I grew up with C I still have a love for some of its oh so simple features like structs. For embedded work, give me a packed struct over complex serialization libraries any day.

        I tend to write a hybrid of the two languages for my own projects, and I’ll be honest I’ve forgotten where exactly the line lies between them.

  • Faresh@lemmy.ml
    link
    fedilink
    arrow-up
    21
    arrow-down
    1
    ·
    9 months ago

    What memory-safe systems programming languages are out there, besides Rust?

      • Faresh@lemmy.ml
        link
        fedilink
        arrow-up
        15
        ·
        9 months ago

        I appreciate your answer, but I mentioned systems programming, because I was more interested in languages that do not rely on a garbage collector.

        • BatmanAoD@programming.dev
          link
          fedilink
          arrow-up
          27
          arrow-down
          1
          ·
          9 months ago

          To play devil’s advocate, most systems programming can be done even with a garbage collector. Midori was a project to build an operating system on a variant of C#, and although the garbage collector did impose technical difficulties, it wasn’t a dealbreaker. Go isn’t usable everywhere Rust is, but it can in fact be used for many things that previously would have been considered “systems” niches (which is part of why there was a somewhat prevalent misconception in the early days of Rust that they were similar languages). Prominent D developers have defended D’s garbage collector (even though it’s technically optional). Bjarne Stroustrup, the creator of C++, used to express great confidence that C++ would one day have a garbage collector.

          …but you’re right, Rust and its rise in popularity (and, conversely, the C++ community’s resistance to adopt anything with garbage collection) have definitely narrowed the common definition of “systems programming” to exclude anything with a “thick” runtime.

    • psudo@beehaw.org
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      9 months ago

      Wasn’t Go designed to be a memory safe systems programming language? I haven’t really used it enough to see if it holds true, though.

        • mox@lemmy.sdf.org
          link
          fedilink
          arrow-up
          11
          ·
          9 months ago

          Segfaults aren’t particularly dangerous. They mean the problem was caught. The program usually just exits.

          Failing to segfault, thereby allowing a bad memory access, is where the real trouble happens.

      • arendjr@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        9 months ago

        Go is almost memory safe, but it does suffer from an issue with its thick pointers (type + address) that can cause race conditions to misrepresent the type of a data structure. This can lead to true segmentation faults and out of bound memory accesses, though it will probably be quite difficult (but not impossible) to exploit them.

  • fubo@lemmy.world
    link
    fedilink
    arrow-up
    18
    arrow-down
    8
    ·
    9 months ago

    Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.

    Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that’s much easier on the programmer.

    And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.

    • SorteKanin@feddit.dk
      link
      fedilink
      arrow-up
      30
      arrow-down
      2
      ·
      9 months ago

      Rust does memory-safety in the most manual way possible

      The most manual way is what C does, which is requiring the programmer to check memory safety by themselves.😛

      Also will say that outside of some corner cases, Rust is really not that harder than Java or Python. Even in the relatively rare cases that you run into lifetimes, you can usually clone your data (not ideal for performance usually but hey its what the GC language would often do anyway). And reliability is far better in Rust as well so you save a lot of time debugging. Compiles = it works most of the time.

      • 520@kbin.social
        link
        fedilink
        arrow-up
        19
        arrow-down
        1
        ·
        edit-2
        9 months ago

        The most manual way is what C does, which is requiring the programmer to check memory safety by themselves.😛

        The difference is, Rust will throw a tantrum if you do things in an unsafe way. C/C++ won’t even check. It’ll just chug along.

        Rust is really not that harder than Java or Python.

        As someone who’s done all three, the fuck it isn’t.

        If you are familiar with C/C++ best practices to any operational level, those things will translate over to Rust quite nicely. If not, that learning curve is going to be fucking ridiculous with all the new concepts you have to juggle that you just don’t with either Java or Python.

        • calcopiritus@lemmy.world
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          9 months ago

          I haven’t been able to compile a single C/C++ program (even bought a C++ book!) Learned to write normal programs in rust (even with simple lifetime annotations!) In 1-2 months. I just knew python and the basic knowledge of 1st year university.

          It’s not that hard.

          Just reading through the rust book (a week, maybe? I don’t remember how much time it took) will make you able to confidently write a simple CLI program.

          • 520@kbin.social
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            9 months ago

            Just reading through the rust book (a week, maybe? I don’t remember how much time it took) will make you able to confidently write a simple CLI program.

            You can do the same in Java or especially Python from zero much, much quicker.

            Also you can learn to go beyond simple CLI programs in those languages much quicker, because you don’t have to worry about memory management.

            • calcopiritus@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              9 months ago

              I’m not saying that java or python are harder, of course they aren’t. I’m just saying that it’s not as hard as people seem to think. What is 1 week of commitment to learn a new language? Of course it depends on what there is to offer.

              I think the benefits of rust far outweigh it’s drawbacks (including the learning time).

      • admiralteal@kbin.social
        link
        fedilink
        arrow-up
        18
        arrow-down
        2
        ·
        edit-2
        9 months ago

        I like Rust a lot, philosophically and functionally… but it is WAY harder. Undeniably very hard.

        Just try and do anything with, say, a linked list. It’s mind-boggling how hard it is to make basic things work without just cloning tons of values, using obnoxious patterns like .as_mut(), or having incredibly careful and deliberate patterns of take-ing values, Not to mention the endless use of shit like Boxes that just generates frustrating boilerplate.

        I still think it’s a good language and valuable to learn/use, and it’s incredibly easy to create performant applications in it once you mastered the basics, but christ.

        • MonkderZweite@feddit.ch
          link
          fedilink
          arrow-up
          1
          arrow-down
          2
          ·
          edit-2
          9 months ago

          It’s mind-boggling how hard it is to make basic things work

          It’s mind-boggling how broken basic things are.

          • admiralteal@kbin.social
            link
            fedilink
            arrow-up
            3
            ·
            9 months ago

            I have not encountered anything broken, aside from maybe binary app docstring stuff (e.g., automated example testing).

            On the contrary, everything seems precise, reliable, and trustworthy. That’s the thing to really like about Rust – you can be pretty much fearless in it. It’s just difficult. I die a bit in time any time I have a return type that looks like Box<dyn Fn(&str) -> Result<Vec<String>, CustomError>> or some shit . Honestly, the worst thing about Rust is probably that you have to manually specify heap vs stack when the compiler could easily make those determinations itself 99% of the time based on whether something is sized.

      • tiredofsametab@kbin.run
        link
        fedilink
        arrow-up
        12
        ·
        edit-2
        9 months ago

        Software engineer for almost two decades at this point, programming off and on since a kid in the late '80s: Rust is harder. It did seem to get better between versions and maybe it’s easier now, but definitely harder than a lot of what I’ve worked in (which ranges Perl, PHP, C, C++, C#, Java, Groovy/Grails, Rust, js, typescript, various flavors of BASIC, and Go (and probably more I’m forgetting now but didn’t work with much; I’m excluding bash/batch, DB stored procedures (though I worked on a billing system written almost entirely in them), etc.)

        That said, I don’t think it’s a bad thing and of course working in something makes you faster at it, but I do think it’s harder, especially when first learning about (and fighting with) the borrow checker, dealing with lifetimes, etc.

        The availability of libraries, frameworks, tools, and documentation can also have a big impact on how long it takes to make something.

    • abhibeckert@lemmy.world
      link
      fedilink
      arrow-up
      14
      arrow-down
      2
      ·
      edit-2
      9 months ago

      A better approach is the one Apple uses with Swift (and before that, Objective-C… though that wasn’t memory safe).

      In swift the compiler writes virtually all of your memory management code for you, and you can write a bit of code (or annotate things) for rare edge cases where you need memory management to do something other than the default behaviour.

      There’s no garbage collection, but 99.999% of your code looks exactly like a garbage collected language. And there’s no performance penalty either… in fact it tends to be faster because compiler engineers are better at memory management than run of the mill coders.

      • roanutil_@programming.dev
        link
        fedilink
        arrow-up
        7
        ·
        9 months ago

        To be fair, Swift uses reference counting instead of garbage collection which has different tradeoffs than GC but does incur a performance penalty.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          9 months ago

          I wish more languages used ref counting. Yes, you have to be careful of circular refs, but the tradeoff is simplicity, speed, lack of needing threads in the runtime, and predictability. Rust gives you special data structures for ref counting for a reason.

          • calcopiritus@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            9 months ago

            Ref counting is just a very basic GC. I’d be surprised if a ref counted language performed better than a GC one. Sure, the program won’t temporarily halt in order to run the GC, but every copy/destroy operation will be slower.

            • seeaya@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              9 months ago

              When Apple introduced the iPhone they required automatic reference counting to be used in Objective-C rather than tracing garbage collection (the language supported both) due to performance reasons (iPhones were significantly slower than Macs). At least Apple seems to think that reference counting is faster than tracing garbage collectors. The compiler can do a lot to remove unnecessary releases and retains. Additionally each retain is just incrementing an integer, and each release is just decrementing an integer and comparing the integer to 0, so the overhead is pretty small.

    • floofloof@lemmy.ca
      link
      fedilink
      English
      arrow-up
      9
      ·
      edit-2
      9 months ago

      I’m no Rust expert, but in what I have done with it I’ve always found it reassuring to know the compiler has my back, and I haven’t found the rules too onerous. In some ways I prefer this to counting on some black-box garbage collector with unpredictable performance costs, and I certainly prefer catching as many errors as possible at compile time not runtime.

  • Simulation6@sopuli.xyz
    link
    fedilink
    arrow-up
    9
    ·
    9 months ago

    The interpreter or compiler could also introduce memory issues into the code. Much less likely to happen, but it is not unknown.

  • xmunk@sh.itjust.works
    link
    fedilink
    arrow-up
    12
    arrow-down
    6
    ·
    9 months ago

    C++ can have excellent performance without ever using a single pointer and avoiding unsafe functions like gets() - this isn’t necessarily a judgment on language - it’s a judgement on bad programming habits.

    Pointers fucking suck, in a modern C++ codebase everything should be pass by value or const/mutable ref. To my preference I’d rather drop mutable refs to force everything to be more functional but whatever.

    • OsrsNeedsF2P@lemmy.ml
      link
      fedilink
      arrow-up
      35
      arrow-down
      2
      ·
      9 months ago

      I mean that’s just the problem with C++. There’s 17 different ways to do things, 2 are always wrong, 14 are contextual, and 1 is reserved for super special cases

      • HornyOnMain@kbin.social
        link
        fedilink
        arrow-up
        16
        arrow-down
        1
        ·
        9 months ago

        And the one you choose is always the one that’s weak to the specific vulnerability you didn’t think of!

    • abhibeckert@lemmy.world
      link
      fedilink
      arrow-up
      16
      arrow-down
      1
      ·
      edit-2
      9 months ago

      Pointers suck in C++. In other languages every single variable is a pointer and it works perfectly with no memory bugs and great performance.

      Pass by value often uses too much memory. Especially if you have a bunch of simultaneous functions/threads/etc that all need to access the same value at once. You can get away with it when your memory is a few dozen integers, but when you’re working with gigabytes of media… you need pointers. Some of the code I work with has values so large they don’t even fit in RAM at all, let alone two or three copies of them. Pass by value could mean writing a hundred gigabytes to swap.

      • xmunk@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        9 months ago

        That’s one reason I mentioned pass by reference “smart” languages will do it automatically depending on the size of the argument, some languages (including my beloved PHP) even have a copy-on-edit functionality where everything is technically passed as a mutable reference but as soon as you mutate it (unless it was explicitly marked as a mutable reference) it will copy the original object and have you edit the copy instead of the original.

        Is being explicit about when copies happen almost always a good thing - yea the overhead of that system is undesirable in performance sensitive situations - but for a high level scripting language it’s quite nice.

    • SorteKanin@feddit.dk
      link
      fedilink
      arrow-up
      19
      arrow-down
      6
      ·
      9 months ago

      Working with habits is just not good enough. C++ has far too many footguns to be considered a safe language and there are frankly objectively better modern alternatives that you should use instead, perhaps except if you have a really large legacy code base you can’t replace (but even then, consider calling into it via FFI from a safe language).

      Even if you tried to actually enforce these habits, you’d just end up inventing a new language and it would be incompatible with previous C++ too.

      C++ is not a viable language for the future.

      • xmunk@sh.itjust.works
        link
        fedilink
        arrow-up
        10
        arrow-down
        1
        ·
        9 months ago

        I get kinda bad vibes from this comment and I’d like to explain why…

        If somebody said “We’re building a point of sale terminal and to make it secure we’re going to be using C++” I’d probably have a dumbfounded expression on my face unless they immediately continued with “because there are libraries we can lean on to minimize the amount of code we need to write.”

        C++ has an extremely mature ecosystem - Qt is essentially it’s own language at this point! There are reasons to still consider building in C++ and saying “C++ is not a language for the future” feels dogmatic and cargo culty to me. Algol, Cobol and Fortran still have programming communities and while I agree that C++ is outsized in presence for the danger it presents there are still good reasons to choose it for some specific domains - high performance graphical programs being one of those in particular.

        C++ has a plethora of foot guns and you need to be aware of them but when you are they’re easy to avoid in fact your quote:

        Even if you tried to actually enforce these habits, you’d just end up inventing a new language and it would be incompatible with previous C++ too.Even if you tried to actually enforce these habits, you’d just end up inventing a new language and it would be incompatible with previous C++ too.

        Is probably the thing I agree most with - well built C++ isn’t incompatible with regular ol’ C++ but it feels like a different language… but as a not too old old-man-developer different projects often feel like different languages - each company/project has tools and libraries they use and it’ll cause code written in the same language to read really differently… I’m a functionally oriented programmer with a pretty particular style, my C++, Python, Java, PHP, Node and Rust all look nearly the same except for language specific peculiarities.

        So yea, discipline is needed and nobody’s default choice should be C++ but if you follow best practices your C++ can be quite safe.

        that all said… I fucking hate the concept of definition files being sseparate from code files so I’m not going to use C++ anytime soon.

    • Feathercrown@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      edit-2
      9 months ago

      just avoid all the bad stuff bro

      If I was giving a tour of my kitchen and it included phrases such as “avoid using the leftmost cabinet of any set of two”, “the freezer doesn’t work but the fridge can be set to the same temperature”, or “the oven has been deprecated, just use the microwave”, you’d rightfully gtfo. Why is this acceptable of a programming language??

    • arendjr@programming.dev
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      9 months ago

      Even references aren’t safe in C++ though, since there’s no borrow checker. Unless you copy everything or use reference counting types everywhere, you’ll still hit plenty of memory-violating footguns. But at that point, why use C++ at all?

    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      A big difference between rust and C++ is that in C++ you say “everyone should passing by value or const ref (mutable ref if needed)”.

      In rust, the default is passing by value. The default refs are consts, you have to explicitly make them mut, and the compiler will warn you if you don’t mutate a mut parameter.

  • crittecol@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    9 months ago

    I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

    In fact, I mostly did this because so many job listings mention it, haven’t even come up with a high-scale game dev problem to solve.

    I’ll probably continue because I find it interesting and no amount of practice is bad, but my question is how is everyone letting this affect their outlook on c++ in their career vs side projects, etc. Really, I’m having a hard time imagining why it was important for this to be said in this way instead of just changing internal policies and job listings.

    • arendjr@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

      I think for game development you don’t need to worry about a shortage of C++ opportunities any time soon. Both Unreal and Godot are built in C++ as well as many in-house engines. Similarly, there are other niches where C++ is king and it would decades for that to change.

      That said, there are certainly areas where C++ is already being replaced by Rust. Areas where both performance and security are important are the first movers, such as webbrowsers, operating system components, but also things like high-frequency traders (crypto ones almost exclusively use Rust, while traditional ones will move slower).

      Personally, I also used to be heavily invested in C++, but I’m happy to have moved to Rust myself. I recently became an independent contractor, and while I would be happy to take contracts involving C++ to migrate them to Rust, I would certainly not start new projects in C++ anymore. But for you, I wouldn’t worry about that yet. The experience you gain working with C++ will help you appreciate Rust more down the line. Just keep in mind that at some point you will be likely to be exposed to Rust too.

  • Adanisi@lemmy.zip
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    15
    ·
    edit-2
    9 months ago

    I’m going to advocate for C here: the sheer simplicity, fast compile times, and power it gives you means it’s not a bad language, even after all these years. Couple that with the fact that everything supports it.

    Rust, while I don’t actually know how to write it, seems much more difficult to learn, slower to compile, and if you want to do anything with memory, you have to fight the compiler.

    And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.

    • Pipoca@lemmy.world
      link
      fedilink
      arrow-up
      12
      ·
      9 months ago

      And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.

      This is facile.

      According to Microsoft, about 70% of security bugs they see are memory safety issues.

      Yes: if you introduce memory safety, there’s still those 30% of security bugs left. But, well, I’d rather worry about 30% of issues than 100%…

      Similarly, I use libraries that eliminate SQL injections unless you really go out of your way.

    • lolcatnip@reddthat.com
      link
      fedilink
      English
      arrow-up
      10
      ·
      9 months ago

      I’ve written quite a bit of Rust and a lot of C and C++ code. I’ll take Rust over C or C++ for any task, including ones where memory safety isn’t a concern. Yes, there’s a learning curve, but overall it’s just more pleasant to use. Now that I’m used to it, writing C++ code feels just as much like fighting the compiler as Rust ever did.

    • carpelbridgesyndrome@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      9
      ·
      9 months ago

      In cases where bugs have been counted they tended to make up the majority of vulnerabilities. Chrome, Firefox, and Windows reported that around 70% of security vulnerabilites were memory corruption. Yes a subset, but the majority of the worst subset.

      • Adanisi@lemmy.zip
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        2
        ·
        9 months ago

        I’ve also heard that unsafe Rust is even more dangerous than C. I guess that’s probably something to do with the fact that you’re always on your toes in C vs Rust? I don’t know. But if you need to do any sort of manual memory management you’re going to need unsafe Rust.

        • IAm_A_Complete_Idiot@sh.itjust.works
          link
          fedilink
          arrow-up
          6
          ·
          9 months ago

          No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren’t allowed to commit UB still. In C++ land I’d venture to guess most any developer won’t care - that’s a bug with your code and not the data structure.

          It’s also more strict because rusts referencing rules are a lot harder then C’s, since they’re all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.

        • carpelbridgesyndrome@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          ·
          9 months ago

          The thing is the whole c program is unsafe. In rust individual parts are marked unsafe. This means auditing should be easier. Also being always on your toes isn’t really viable. Breaking down the program into safe vs unsafe is probably an improvment

        • lolcatnip@reddthat.com
          link
          fedilink
          English
          arrow-up
          3
          ·
          9 months ago

          Unsafe code should be a very, very small part of any Rust codebase. Lots of major libraries have a policy against including any unsafe code at all, because 99.9% of the time you can do just as well with safe cost. The major exception is when you need to call C code.

        • Rustmilian@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          7 months ago

          I’ve also heard that unsafe Rust is even more dangerous than C.

          Utterly Untrue :
          It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

      • Adanisi@lemmy.zip
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        9 months ago

        The… programming community?

        I might adopt Rust, I have no hard feelings against it, I just like not fighting with the compiler and having the fastest execution possible.

        But hey, even Lemmy needs some hot takes to keep it lively.

    • crimsonpoodle@pawb.socialOP
      link
      fedilink
      arrow-up
      3
      ·
      9 months ago

      Maybe it’s just because I haven’t had to deal with the scenario yet but does compile time really matter? I mean for small programs it seems it’s almost instant on modern machines and for large programs I would assume, if it exists, that you would be using the equivalent of make so you would only be recompiling the small changes made.

      • fruitycoder@sh.itjust.works
        link
        fedilink
        arrow-up
        3
        ·
        9 months ago

        Compile times are a barrier. How much of hurdle that really is depends on the project and dev. Like readability, accessabilty, friendlyness, license and userbase it all adds up to who can work on the project.

        I know in the DevX space the rule of the thumb is you want to have devs see results of a commit before the urge to check their phone/other tabs wins over because that context switching is timly for them.

    • okamiueru@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

      Zig is a pretty interesting alternative to C

      Pretending Rust means no more exploitation is stupid.

      I guess? Are you alluding to someone or something in particular?

  • dohpaz42@lemmy.world
    link
    fedilink
    English
    arrow-up
    20
    arrow-down
    26
    ·
    9 months ago

    I’m going to probably be downvoted to Hell, but I disagree wholly that it’s the language’s fault that people can exploit their programs. I’d say it’s experience by the programmer that is at fault, and that’s due to this bootcamp nature of learning programming.

    I’d also blame businesses that emphasize quantity over quality, which then gets reflected in academia because schools are teaching to what they believe business wants in a programmer. So they’re just churning out lazy programmers who don’t know any better.

    There needs to be an earnest revival of good programming as a whole; regardless of language, but also specifically to language. We also need to stop trying to churn out programmers in the shortest time possible. That’s doing no one any good.

    That’s my two cents.

    • words_number@programming.dev
      link
      fedilink
      arrow-up
      25
      ·
      9 months ago

      Id say it’s experience by the programmer that is at fault, and that’s due to this bootcamp nature of learning programming.

      You are getting downvoted, because this is factually proven wrong by studies and internal analysis of several huge companies (e.g. google/android and microsoft). A huge number of exploitable bugs are preventable using memory safe languages, nowadays even without performance costs (Rust).

      Apart from that your point is orthogonal to the point of the post. You can have better trained coders and have them use better, safer technologies.

      We could also just train every driver more thoroughly including mental training and meditation to make sure they are more calm and focussed when driving and we maybe wouldn’t need seatbelts anymore. But:

      1. Is that a realistic scenario?
      2. Why not use seatbelts anyway, so there’s a higher chance of not dying if some driver didn’t sleep well that day?
    • andyburke@fedia.io
      link
      fedilink
      arrow-up
      24
      arrow-down
      1
      ·
      9 months ago

      Gently, I would ask you to think about yourself in a future role where you have too little time, and are under too much pressure, and you haven’t gotten enough sleep, and you’re distracted on this particular day, and you happen to make a mistake, leave out a line, forget to fix a section of code you were experimenting with…

      And even if you, a paragon of programming power and virtue, would never find yourself able to be hurt by your tools, you must surely know that mortals have to work with them as well, right?

    • fidodo@lemmy.world
      link
      fedilink
      English
      arrow-up
      18
      ·
      edit-2
      9 months ago

      Even the best programmers are going to make mistakes at times. Saying the solution is to just be perfect all the time is impossible.

    • Kissaki@programming.dev
      link
      fedilink
      English
      arrow-up
      15
      ·
      edit-2
      9 months ago

      Memory safety issues were a thing even before bootcamps and “bootcamp culture”.

      Even if you fix expertise, intention, and mindset - the entire workfield environment and it’s people - mistakes still happen.

      If you can categorically evade mistakes and security and safety issues, why would you not?

    • TechNom (nobody)@programming.dev
      link
      fedilink
      English
      arrow-up
      13
      arrow-down
      1
      ·
      edit-2
      9 months ago

      but I disagree wholly that it’s the language’s fault that people can exploit their programs. I’d say it’s experience by the programmer that is at fault, and that’s due to this bootcamp nature of learning programming.

      Considering that even the best programmers in the world can’t write correct programs with C/C++, it’s wrong to absolve those languages of the massive level of memory safety bugs in them. The aforementioned best programmers don’t lack the knowledge needed to write correct programs. But programmers are just humans and they make or miss serious bugs that they never intended. Having the computing power to catch such bugs and then not using it is the real mistake here. In fact, I would go one step further and say that it isn’t the language’s fault either. Such computing power didn’t exist when these languages were conceived. Now that it does, the fault lies entirely with the crowd that still insist that there’s nothing wrong with these old languages and that these new languages are a fad.

    • lolcatnip@reddthat.com
      link
      fedilink
      English
      arrow-up
      4
      ·
      9 months ago

      All programmers make mistakes that cause memory safety errors if the language doesn’t protect them. This is a well documented fact, not an opinion.

    • crimsonpoodle@pawb.socialOP
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      9 months ago

      While I agree wholeheartedly with the idea that we need to emphasize quality over quantity, so long as software pays well there will be people who don’t care. In my university I’ve met a fair few people that complain about having to learn about compilers, assembly, and whatnot because “I’ll never need to know that in my actual job”. While to some extent in the United States you can blame the fact that classes just cost a ton, I think it’s a sad reality that, barring some key change in the way our whole education and economic systems work, there will be unimaginative apathetic people that will ruin things for the rest. Plus people are fallible or something I dunno. But yeah void pointers are my jam because I don’t have to wait precious clock cycles making new ones jk.

    • nomadjoanne@lemmy.world
      link
      fedilink
      arrow-up
      3
      arrow-down
      9
      ·
      9 months ago

      Absolutely. The problem is, most programmers are mediocre. So sadly the protection of stupid people tends to take cultural precedence.

  • CaptainProton@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    12
    ·
    9 months ago

    Oh yes, improve security by mandating that everyone uses higher level languages that encourage importing libraries.

    I hate to pull the AI card, but AI has a better chance of catching low level language type issues than forcing people to use tools they didn’t want to has of accomplishing anything positive.