4 ms·

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.

by 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.
    - laumars 9y ago
      You're talking about just over a month. I think it's a little unfair to expect people to maintain hobby projects every week of every year. Particularly over Christmas and the new year when our lives are often busier than usual. To use a personal example, an open source project I actively maintain only yesterday saw it's first commits since the end of November. But I am still very much committed to that project.
- 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.

by sho_hn 9y ago

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.
  - laumars 9y ago
    You're talking about just over a month. I think it's a little unfair to expect people to maintain hobby projects every week of every year. Particularly over Christmas and the new year when our lives are often busier than usual. To use a personal example, an open source project I actively maintain only yesterday saw it's first commits since the end of November. But I am still very much committed to that project.
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.