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
    31
    arrow-down
    1
    ·
    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
      9
      arrow-down
      6
      ·
      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
        7
        arrow-down
        1
        ·
        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
          3
          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
            1
            ·
            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.

      • cm0002@lemmy.world
        link
        fedilink
        arrow-up
        6
        arrow-down
        7
        ·
        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.

        • Croquette@sh.itjust.works
          link
          fedilink
          arrow-up
          4
          ·
          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.

        • pycorax@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          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.