No announcement yet.

Should GNOME Begin Replacing More C Code With Rust?

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by spstarr View Post

    Sure, bindings, but not the core of GNOME, it's always been C.
    Sure but since bindings are being used by core applications, I don't see any hatred.


    • #12
      I think it is a good idea. I see many benefits (thread safety while being performant, no GC, zero cost abstractions, no need of maintaining Vala, Rust will have broad support).


      • #13
        Originally posted by jacob View Post
        In principle it would be a nice idea, it would allow Gnome to benefit from a modern and powerful language yet remain binding-friendly. But it might be a little bit too soon for that, Rust is still very young and moves quite a lot.
        The Rust language is stable since the 1.0 release in Mai 2015 and the core team is really eager to to keep the compiler backward compatible. They wont introduce any breaking change in the stable version.

        What you probably mean are the 3rd party libraries, most of them pre-1.0. That's true, some of them are marked unstable, but one of the goals for 2017 is to get more important libraries ("crates" in Rust) to a stable 1.0 version.


        • #14
          Oh and I'm also for GNOME replacing C code with Rust!


          • #15
            Yes! Absolutely! Rust is very nice and provides so much safety. I think would benefit both GNOME and rust. It is minimal and compiles down well (like vala but better because it doesn't require connect). Also, the gnome devs can use it OOP or not - it's their choice. I think that had rust been in its current state 10 years ago vala would not exist.

            Fyi, I like the idea behind vala - to provide modern languages features but not have a runtime and have language bindings easy. I wish vala could be more of a language and have its own IR and llvm front end. I think compiling to c first you lose the chance to optimize it as vala (such as the relationships and restrictions it has - once it is in c, it to more general purpose so guarantees are gone).


            • #16
              No. Just make C11 the baseline.


              • #17
                There's no good reason to not choose Rust. The sheer number of bugs that would be fixed just from the movement to Rust would be worth it in itself.


                • #18
                  Originally posted by spstarr View Post

                  Sure, bindings, but not the core of GNOME, it's always been C.
                  If GTK+ would be written in OOP language, such as C++, it would be hard to use in other languages.
                  Just look at QT. How many languages have good, complete bindings for QT? C++ (no bindings, native language), C#, maybe Python to some degree and this is all.


                  • #19
                    Do what ever you want, GTK3 proved to be a mess in the end. And gnome only became bigger and bloated. So I don't care, I've stopped using gnome time ago and wasn't thinking into comming back anyway.


                    • #20
                      Perhaps. But that wouldn't be enough, by far.

                      1. They haven't changed project name for ages. Everyone knows that project name is essential. It has to be clever acronym, preferably recursive, if possible with esoteric or mythical component.

                      2. Your project leader has to have "modern" worldviews and extreme, even, when within modern perspective.

                      3. Aforementioned personal views have to be tied to a project and proclaimed at every possible opportunity - at every project installation, at every news notice, at every physical event etc.

                      4. S/he has to tick as many of the minority groups as possible. Merely having a woman or black is pathetic, even in combination.

                      You need to really step out of the crowd and find someone that:

                      - is never really singular in biological sense. LIke those cojoined twins. Or even better, triplets, if you can find them. You need to find ones that share cranium, but _not_ brain.
                      - s/he has to go thrugh sex change, at least once. And end up as one of those _other_ , non-classical 57 legally defined sexes ( look recent German law).
                      -s/he has to be of some esoteric race and nationality combo, for example Albino Black Nigerian Swede. With undefined, gradiental eye colour/s, unique on each eye, on each head.
                      -s/he has to use solely some equally esoteric, rare AND dead language.
                      -s/he has to have sexual orientetions and views such that even if caught in the middle of Alleppo, ISIS would behead _itself_.
                      Once was being anti-gay the norm, it was replaced by anti-anti-gay, but even that was obsolete some time ago, after being gradually escalated to extreme. So now you are looking for someone that practices bukkake merely for a daily protein diet and procreates through ritualistic "surgery" + gene "management" of some sort. Good starting point would be a sperm sampling + sex change to female + insemination with own archived sperm + 17yr wait time for bootstrap phase to mature + repeat the insemination on throwaway stage to get granchildren "directly".

                      5. actual programming language choice is probably more like 50-th, not 5-th step, but even here you need something that is not merely a language. Just as mere VM are passe and bytecode thingies are for pussies. Fuck Rust and OO. You need _quantum_ object oriented not-language but paradigm. Why fuck around with inheritance if every object already is/ins't a Schredinger's cat? You need something that might be executed on quantum computers that are being speculated on being thought about in next 10 or 20 years. Ofcourse such language would mandate existence of infinite universes and hardware that would enable IPC and virtuality across universe barriers. And ofcourse JIT capability and not just HW, instant garbage collection but _garbage_universe_ collection.