Announcement

Collapse
No announcement yet.

SixtyFPS 0.1 Released As A Rust-Focused Graphical Toolkit

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

  • #21
    Originally posted by kpedersen View Post
    Honestly, memory leaks are the least of my worries. It is usually the fact that many wrappers just churn out a raw pointer and just expect me to guess at its lifespan. Sure, my guess might be educated but the fact still remains it can't be verified.
    RAII certainly helps to prevent memory leaks, but they also help with issues like locking/unlocking some resource and similar issues that effect the correctness of a program. It (and other concepts in C++) can prevent classes of errors a C programmer has to watch out for.

    Rust adds some more classes of errors on top of what C++ protects against. E.g. ownership of things and transfer of ownership tends to be way more expressive in rust than in C++. That does of course not prevent every error you can have in your code, but it adds on top of what C++ adds over C.

    E.g. you can still leak memory in rust (which is a perfectly safe thing to do;-), but you do not have to think about dangling pointers very much in safe rust -- and safe rust is the fast majority of the code.

    I really found it very enlightening to look into rust a bit: Learning rust definitely made me a better C++ programmer! The rust compiler is a very patient teacher about memory issues you run into using C++ as well -- and which usually do not cause any trouble at all ;-)

    Comment


    • #22
      Originally posted by krzyzowiec View Post

      Well you know what they say about writing bug free C/C++ code: Anyone who thinks they can, can’t.
      You don't have to name a language for that. Any programming language allow the creation of bugs so it does not matter if the language protects anyone from blatant errors, bugs will happen anyway (not to mention that programs runs on top of buggy OSes who runs on top of buggy CPUs who are soldered on less-than-stellar motherboards who are feeded by failing alimentations that are receiving current from problematic grids. So...).

      [1] as in "you, not you in particular, but, you [2] know..."
      [2] as in "and I mean you, personnally".

      Comment


      • #23
        Originally posted by krzyzowiec View Post

        Well you know what they say about writing bug free C/C++ code: Anyone who thinks they can, can’t.
        Designing software isn't about not writing bugs, it's about planning everything out, the design and tooling, so that the likelihood of writing/designing bugs is reduced. The idea behind climbing a mountain isn't about being skilled enough to not fall off, it's about being prepared enough to not fall off, and accounting for what will happen if you do. This is why I follow methodologies like fail-fast, an incorrect program shouldn't even try to run in the first place.

        Comment


        • #24
          Originally posted by kpedersen View Post
          Qt... So what the project is saying that they are still 100% dependent on C++ and the Rust is basically a "safe" sprinkling on top of layers of potentially memory unsafe code.

          Annoyingly Rust is currently such a dependent language. I suppose this is a toss up between safety vs a mess of dependencies.

          Hopefully one day a language will appear where we can shed dependencies *and* have safety.
          Not possible. Any new language will have to create replacements for what software already exists, or layer atop existing software. Rust is "dependent" to the extent that C and C++ have defined the computing world. It will take many decades if ever to replace them. What I wonder is why the builder pattern became so popular within the Rust community. Default parameters completely eliminate that pattern, as you can see in Kotlin. It's not terrible for a user, but it's a lot of boilerplate to write for such a simple feature.

          Oh well. No language is perfect I suppose.

          Comment

          Working...
          X