3 ms·

You're comparing a language to an OS and three GUI frameworks.

by rapsey 9y ago

sho_hn 9y ago
I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics. IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust. That said - of course C++ was around quite a while before being adopted by Qt.
- rapsey 9y ago
  Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.
  - IshKebab 9y ago
    There's a project called Limn trying to do this. I doubt it has solved the ergonomics issue though.
    - rapsey 9y ago
      Anyone pinning hope on limn should take a look at the activity on the project since start of December.
      - littlestymaar 9y ago
        I wouldn't be too pessimistic about a project just because the main author stopped pushing changes for one month in the holliday season. It also happened in August for the same project and work resumed later at a fast path.
        coldtea 9y ago
        If the project has only one main author, I would be. Even more so if they are on and off and not paid for it. Heck, TextMate and somewhat Sublime Text had such issues with 1 single dev, and those are projects that actually make them money...
        laumars 9y ago
        That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.
        rapsey 9y ago
        > it would be trivially easy for any number of other developers fork the git repo and carry on the work. Expecting that is wishful thinking. The fact of the matter is making something like that is an insane amount of tedious work and 99% of the time it is started up by people playing around with the concepts and abandoned once the initial fun problems are tackled. Something I am sure will happen with limn.
        laumars 9y ago
        I agree however that could equally happen with any similar Rust UI library that isn't backed by a corporate entity. And seeming as there isn't any corporate backed UI libraries for Rust (at least that I'm aware of), you're literally no worse off with limn than you are with anything else.
  - sho_hn 9y ago
    > a sane electron type library There's no version of that concept that's sane at this time, though. Wrapping full-fidelity APIs the browser engine has access to in a lossy abstraction layer of shoddy web platform APIs isn't a practice Servo can improve upon. It takes improving those APIs.
- vvanders 9y ago
  Qt uses way more than vanilla C++ though, it practically has its own dsl for a whole host of things.
  - sho_hn 9y ago
    This often gets over-reported; old memes die hard. There's a small number of macros that a custom preprocessor expands to (very pedestrian) generated code, but they are optional to use (though it's certainly uncommon not to use them) and these days there's template-based versions of some of them that are preferred and steadily finding adoption over the macro ones because they're superior. Beyond that there's a few more normal preprocessor-based macros that are entirely optional. In that sense Qt also tracks vanilla C++ very closely and has adopted features from newer language versions at a fairly steady pace and swiftly for such a large production library set. None of this matters much to my point though - that was about much more basic language semantics like classes-based OOP and the absence of ownership rules.
pjmlp 9y ago
No, I am comparing the selection of a specific programming language, given the existence of tooling for a specific purpose. I need to fulfil task X, with tool Y, then I choose language Z among those supported by Y. Not I chose language Z, then try to find some kind of Y, that helps me solve X somehow. When C++ came into the picture we got Turbo Vision on MS-DOS bundled with Borland compilers, Apple adopted Metrowerks tools and used PowerPlant, OS/2 promoted CSet++, UNIX guys were into Motif.h++. Then came Windows, Borland pushed forward with OWL followed by VCL. Microsoft created MFC, adopted by Symatec and Zortech compilers. Apple eventually went Cocoa, and Microsoft UWP as of latest. And then there is Qt, literally the only game in town for C++ GUIs not related to any OS vendor. Followed by what in possible in Java and .NET eco-systems. All with good visual tooling support, allowing for productive workflows between developers and designers. I am not saying that Rust some day won't catch up, and offer something similar in terms of productivity. I hope it does, but right now in 2018 it doesn't.

You're comparing a language to an OS and three GUI frameworks.

by rapsey 9y ago

You're comparing a language to an OS and three GUI frameworks.

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics. IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust. That said - of course C++ was around quite a while before being adopted by Qt.

rapsey 9y ago
Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.
- IshKebab 9y ago
  There's a project called Limn trying to do this. I doubt it has solved the ergonomics issue though.
  - rapsey 9y ago
    Anyone pinning hope on limn should take a look at the activity on the project since start of December.
    - littlestymaar 9y ago
      I wouldn't be too pessimistic about a project just because the main author stopped pushing changes for one month in the holliday season. It also happened in August for the same project and work resumed later at a fast path.
      - coldtea 9y ago
        If the project has only one main author, I would be. Even more so if they are on and off and not paid for it. Heck, TextMate and somewhat Sublime Text had such issues with 1 single dev, and those are projects that actually make them money...
        laumars 9y ago
        That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.
        rapsey 9y ago
        > it would be trivially easy for any number of other developers fork the git repo and carry on the work. Expecting that is wishful thinking. The fact of the matter is making something like that is an insane amount of tedious work and 99% of the time it is started up by people playing around with the concepts and abandoned once the initial fun problems are tackled. Something I am sure will happen with limn.
        laumars 9y ago
        I agree however that could equally happen with any similar Rust UI library that isn't backed by a corporate entity. And seeming as there isn't any corporate backed UI libraries for Rust (at least that I'm aware of), you're literally no worse off with limn than you are with anything else.
- sho_hn 9y ago
  > a sane electron type library There's no version of that concept that's sane at this time, though. Wrapping full-fidelity APIs the browser engine has access to in a lossy abstraction layer of shoddy web platform APIs isn't a practice Servo can improve upon. It takes improving those APIs.
vvanders 9y ago
Qt uses way more than vanilla C++ though, it practically has its own dsl for a whole host of things.
- sho_hn 9y ago
  This often gets over-reported; old memes die hard. There's a small number of macros that a custom preprocessor expands to (very pedestrian) generated code, but they are optional to use (though it's certainly uncommon not to use them) and these days there's template-based versions of some of them that are preferred and steadily finding adoption over the macro ones because they're superior. Beyond that there's a few more normal preprocessor-based macros that are entirely optional. In that sense Qt also tracks vanilla C++ very closely and has adopted features from newer language versions at a fairly steady pace and swiftly for such a large production library set. None of this matters much to my point though - that was about much more basic language semantics like classes-based OOP and the absence of ownership rules.

pjmlp 9y ago

No, I am comparing the selection of a specific programming language, given the existence of tooling for a specific purpose. I need to fulfil task X, with tool Y, then I choose language Z among those supported by Y. Not I chose language Z, then try to find some kind of Y, that helps me solve X somehow. When C++ came into the picture we got Turbo Vision on MS-DOS bundled with Borland compilers, Apple adopted Metrowerks tools and used PowerPlant, OS/2 promoted CSet++, UNIX guys were into Motif.h++. Then came Windows, Borland pushed forward with OWL followed by VCL. Microsoft created MFC, adopted by Symatec and Zortech compilers. Apple eventually went Cocoa, and Microsoft UWP as of latest. And then there is Qt, literally the only game in town for C++ GUIs not related to any OS vendor. Followed by what in possible in Java and .NET eco-systems. All with good visual tooling support, allowing for productive workflows between developers and designers. I am not saying that Rust some day won't catch up, and offer something similar in terms of productivity. I hope it does, but right now in 2018 it doesn't.