Announcement

Collapse
No announcement yet.

SixtyFPS 0.1 Released As A Rust-Focused Graphical Toolkit

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

  • #11
    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.
    You can still implement safety in an unsafe language, you just have to be very, very careful about verifying that it's completely safe. NASA already has to do this with their rover software written in pure C, which would cost them billions of dollars if it failed at runtime. Rust just makes it much easier to verify your software is safe, but it's not magic. C/C++ already has tons of tools, libraries and methodologies for writing safe code, it's just more effort to consistently use them as opposed to Rust doing it automatically.
    I love Rust, but I can't stop thinking about a comment someone once said, it was only made by Mozilla because their programmers were too incompetent to not write memory leaks. I appreciate Rust for the power and respect it gives me as a very modern and fresh language built on the decades of language research we've done, not because it's the low-level programmer's equivalent of a soft-spot helmet. If "safety" was all you cared about then you may as well use languages made for actually mentally-challenged people like Python or Java.

    Comment


    • #12
      I bet uid313 will love this

      Comment


      • #13
        Originally posted by Vistaus View Post
        I bet uid313 will love this
        I don't know. There are already GTK4 bindings for Rust.
        I haven't tried the GTK4 bindings yet though, I've only very little experimented with the GTK3 bindings and as a Rust noob who I struggled, maybe they're not so good, maybe there are other toolkits. Rust already have other widget toolkits such as OrbTk and many others.

        Comment


        • #14
          Originally posted by sh4nks View Post
          It's great to see that for once Qt is used instead of GTK.
          authors of subj are ex-kde/qt devs

          Comment


          • #15
            Originally posted by Ironmask View Post
            I love Rust, but I can't stop thinking about a comment someone once said, it was only made by Mozilla because their programmers were too incompetent to not write memory leaks. I appreciate Rust for the power and respect it gives me as a very modern and fresh language built on the decades of language research we've done, not because it's the low-level programmer's equivalent of a soft-spot helmet. If "safety" was all you cared about then you may as well use languages made for actually mentally-challenged people like Python or Java.
            Hehe, I could believe it (admittedly as a Firefox user. Their developers have "good" days and "bad" it seems ). Nothing can really prevent code from being bad and designing a language for a lowest common denominator of mentally-challenged people is certainly not ideal (same with DEs!). Though I do prefer languages that can be verified memory safe *and* portable. C has the latter but not the former whereas Rust has the former (if pure which is rare) but with the number of dependencies that get dragged in for the most trivial of things, I certainly can't say it is portable.
            Though then there is the debate of if the added verification makes people sloppy. I personally feel I *need* to know my code has some semblance of safety but it is impossible to 100% guarantee.

            (Python and Java are safe though decades of testing but they certainly aren't portable. The very idea of trying to get the JVM to run on a novel architecture makes me shudder).

            I have some pretty good solutions for C these days actually providing better results than AddressSanitizer in some areas (C++ is much more nasty to verify) and have yet to ever see a single project in pure Rust so can't really comment on its perceived safety.
            Last edited by kpedersen; 20 August 2021, 03:56 PM.

            Comment


            • #16
              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.
              Well, Qt is a way to get nativ-looking widgets now and it will get replaced over time. It is _already_ optional -- if you are happy to have non-nativ widgets in your application.

              Have you ever seen C++ wrappers around C libraries? Those shield a programmer from some of the pits a C programmer could fall into. E.g. RAII allows to make sure cleanup code is run in C++, that a C programmer needs to remember to put in manually. Are those wrappers useless as they rely on less safe C code? No, they are actually really helpful: A users of that wrapper has less chances to cause bugs! And any successful library has way less code than there is code using that library.

              A Rust wrapper around a C or C++ library does pretty much the same: It covers some sharp edges that somebody using the bare library could cut themselves on.

              Comment


              • #17
                So it has buttons and underlined buttons, comes it multiple licenses, you can use multiple languages. Only question is does it actually do any thing?

                Comment


                • #18
                  Originally posted by kpedersen View Post

                  Hehe, I could believe it (admittedly as a Firefox user. Their developers have "good" days and "bad" it seems ). Nothing can really prevent code from being bad and designing a language for a lowest common denominator of mentally-challenged people is certainly not ideal (same with DEs!). Though I do prefer languages that can be verified memory safe *and* portable. C has the latter but not the former whereas Rust has the former (if pure which is rare) but with the number of dependencies that get dragged in for the most trivial of things, I certainly can't say it is portable.
                  Though then there is the debate of if the added verification makes people sloppy. I personally feel I *need* to know my code has some semblance of safety but it is impossible to 100% guarantee.

                  (Python and Java are safe though decades of testing but they certainly aren't portable. The very idea of trying to get the JVM to run on a novel architecture makes me shudder).

                  I have some pretty good solutions for C these days actually providing better results than AddressSanitizer in some areas (C++ is much more nasty to verify) and have yet to ever see a single project in pure Rust so can't really comment on its perceived safety.
                  100% rust pastel.... https://github.com/sharkdp/pastel

                  Comment


                  • #19
                    Originally posted by Ironmask
                    I love Rust, but I can't stop thinking about a comment someone once said, it was only made by Mozilla because their programmers were too incompetent to not write memory leaks.
                    Well you know what they say about writing bug free C/C++ code: Anyone who thinks they can, can’t.

                    Comment


                    • #20
                      Originally posted by tobias View Post
                      Have you ever seen C++ wrappers around C libraries? Those shield a programmer from some of the pits a C programmer could fall into. E.g. RAII allows to make sure cleanup code is run in C++, that a C programmer needs to remember to put in manually.
                      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.

                      Basically what I want is shared_ptr / weak_ptr counterparts everywhere but this is not really feasible due to overhead / mentality. Not to mention shared_ptr do not protect against dangling "this" in very poorly formed programs. Sure these programs need to be fixed but when you are given a massive program to maintain, C++ certainly doesn't help you find the flaws.

                      Comment

                      Working...
                      X