8 ms·

Why is every project on the HN front page these days Rust this, Rust that? I understand the enthusiasm, but sometimes it seems a bit much. Oh, this is my post.

• gostsamo 6y ago
  Thanks for putting accessibility on the first row of priorities.
• benatkin 6y ago
  I think it's ideal content for HN. Programming languages have always been a big deal here, since the day HN was created.
  • throwaway894345 6y ago
    I certainly enjoy content like this a lot more than the "X startup exited for $Y million" content.
    • imtringued 6y ago
      Or the countless single person startups that shut down before you even knew of their existence.
  • acidbaseextract 6y ago
    I came to HN for the lisp fanboy culture when it washed out of reddit, and stayed for the great moderation.
• deleted 6y ago
  [deleted]
• andy_ppp 6y ago
  Why not just take the React-native model and port it to Rust (whatever that translates to)? From my POV for 85%+ of things it’s good enough and would be fairly simple to implement.
  • k__ 6y ago
    While I'm all for React-Native, the opinions on how to do cross-platform GUI differ. Some say, use native UI elements, like React-Native. Some say, render your own stuff in a (GL) canvas, like Flutter/Revery.
    • d0100 6y ago
      Some say, render your own stuff in a (GL) canvas, like Macromedia Flash
  • zellyn 6y ago
    Raph's previous post (linked in the first paragraph) goes into more detail than you could imagine on the options and differences and tradeoffs involved…
    • andy_ppp 6y ago
      Thanks! I’ll check it out
  • oblio 6y ago
    You mean that they should wrap native controls? It's not React Native's model, it has been around since forever. WxWidgets (https://en.wikipedia.org/wiki/WxWidgets https://en.wikipedia.org/wiki/WxWidgets) 1992 SWT (https://en.wikipedia.org/wiki/Standard_Widget_Toolkit https://en.wikipedia.org/wiki/Standard_Widget_Toolkit) 2003 Or if you mean React itself, I found this blog post kind of funny: https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/ :-)
    • andy_ppp 6y ago
• turbinerneiter 6y ago
  What is your opinion on the relationship of the GUI toolkit with the operating system?
  • raphlinus 6y ago
    That's a pretty broad question, but overall I favor deeper integration with operating system and platform capabilities. Some people see GUI as something to be built over an abstraction layer consisting of delivery of mouse and keyboard events, plus a fast pipeline to render pixels. I think that misses some opportunities. This is one reason I'm really enjoying Rust. When it comes time to do some platform integration, you just haul out the unsafe keyword and write it, nothing in your way. By contrast, when I was working on Android and had to do a lot of JNI, it was painful.
  • ncmncm 6y ago
    Can't answer for Raph, but deeper integration with the OS interferes with portability. You need enough integration for things to work at all, but after that, integration is in competition with portable features for developers' attention. Attention is always the scarcest resource, all up and down the stack.
• mtalantikite 6y ago
  I don’t know why, but this reminded me of HN about a decade ago when people would post Erlang articles en masse as a means to make sure non-technical people were bored and wouldn’t hang around. I guess it didn’t work in the long run!
  • ncmncm 6y ago
    Oh, is that why?
• deleted 6y ago
  [deleted]
• mwcampbell 6y ago
  > I wouldn’t consider a toolkit “ready” for production use until it supported accessibility, and as far as I know there is nothing in the Rust space even starting to work on this. Have you given much thought to the design of Druid's accessibility layer yet? I might be able to help with that and with a Windows UI Automation implementation in my spare time (a stable com-rs would help with that). I guess this isn't much of a priority though for your hero app (Runebender).
  • raphlinus 6y ago
    Help on this is more than welcome. It's also not as far off the roadmap as you might think. I know of at least three very talented font designers with disabilities, at least one who uses a wheelchair. It would please me enormously to make a tool suitable for them, and I would push other priorities back for it, just because I consider it so important. In any case, I haven't done detailed design work on accessibility, but enough poking around to get some sense of what might be involved. You are right that stable com-rs will help a lot with this kind of integration; there are soundness and other issues with the custom com implementations we've had to do. Fortunately there are good people working on it.
• ncmncm 6y ago
  Kudos for adopting the "dynamic range" concept. I agree that accessibility support is a good proxy for maturity. Even if somebody tries to game perception by doing accessibility "early", there are benefits. On that topic, what are GTK's and Qt's accessibility support like? I remember that once when there was a real prospect of Free Software being made preferred for public acquisitions, somewhere, a big disabled-support group argued that the Free Software stacks lacked accessibility support, and would shut them out. Would such an objection be plausible today?
  • gnud 6y ago
    Qt supports the native platform accessibility on Windows and Mac, and "AT-SPI" on X11 [0]. Windows and Mac has been supported since at least Qt 4 in 2005. I think there was also some support in Qt 3. The archived Qt 4 documentation says X11 support is "preliminary". 0: https://doc.qt.io/qt-5/accessible.html https://doc.qt.io/qt-5/accessible.html
• jakear 6y ago
  What's the development experience scene like for Rust GUIs? In my experience developing Electron apps there are a a couple major plusses that I'm not sure Rust can compete with, based only on my limited knowledge of the ecosystem: - Excellent embedded developer tools. Hundreds of thousands of engineer-hours have gone into the chromium devtools, providing everything from styling overrides to layout metrics to profiling tools to a REPL to DOM tree inspection and modification, to an integrated debugger, etc etc etc, and all of that is at your disposal with a simple Cmd+Opt+I. To my knowledge Rust doesn't have anything like this. - Super quick incremental updates. Making a change and seeing the impact is sub-second, even on large projects (vscode). Based on my understanding of rust, recompilation can take a very very long time. When making GUI's a lot of the time is spent making finicky little changes and reloading -- if that inner loop is slow you're going to have a bad time.
  • raphlinus 6y ago
    I've talked up the strengths, you've brought up the big weaknesses. I think there is some interesting work on both of these fronts, but the developer experience situation is very primitive so far by comparison. Compile times have been getting better. For reference, on my machine an incremental build of Runebender is 2.3s. Part of this reflects some choices we've made to use platform capabilities rather than build the entire stack ourselves.
    • pornel 6y ago
      DevTools is the killer feature. I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live. DevTools is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.
      • 6y ago
• samatman 6y ago
  This is coming from an outside perspective, and I'm quite prepared to be badly wrong. I think the Rust language needs to learn a few tricks from Objective C and Swift to really make this possible. In particular the work being done on extensible protocols. What you can do, is build a 'Rust-flavored' GUI library. But this isn't what users want: they want a native app, while developers want to write once-run anywhere. This requires a kind of double decoupling, where UI intent is expressed as an abstraction, and is realized as an OS-native control — but one which itself will dynamically update, insofar as possible, as the OS evolves. This calls for a kind of API wizardry which Objective C always got right, and C++ never really did. I see that dichotomy extending into Swift and Rust, but it isn't inevitable, Rust hasn't painted itself into that particular corner. Anyway, it's encouraging to see this work happening, I wish you good fortune in 2021 and beyond.
  • mwcampbell 6y ago
    Check out Raph's retrospective on his xi editor project [1], particularly the section "There is no such thing as native GUI", for his take on why using platform-provided ("native") controls isn't always practical, at least for the applications he's developing. Anyway, cross-platform wrappers over native controls have been done in other languages, e.g. wxWidgets in C++ and SWT in Java, and that approach has enough limitations that AFAIK most developers of complex applications avoid it now. [1]: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
    • pornel 6y ago
      I will miss dearly the good old days of Cocoa GUIs that adhered to Apple's Human Interface Guidelines (and when HIG itself was about usability, not looks). They all supported all the little things of Cocoa (like click-hold-drag on popup menus activating items on mouseup, or proxy icons that gave quick access to files of documents in any window, or search pasteboard). Nowadays native apps on Mac are dead. Even Apple is giving up. There are still native-code-running .app bundles, but they're Qt, Electron, or Catalyst that are like knock-off brands of Mac apps. Even if they bother to have vaguely Mac-like skin, they lack all of the nice little details that made Cocoa apps great.
• deleted 6y ago
  [deleted]
• phkahler 6y ago
  Two things. IMHO (of course) and GUI toolkit needs to be usable from other languages, I hope that's part of the plan. And also, Don't use platform-specific features or be a wrapper over their widgets. Be a GUI toolkit that works everywhere. Good luck!
• stjohnswarts 6y ago
  It came out as programmer's favorite language for the past few years so it shouldn't be a surprise. You should be posting articles for your favorite language and let it float to the top.
• fluffything 6y ago
  Why isn't Xi a "hero" app for this anymore?
  • raphlinus 6y ago
    1. As your question touches on, it was. The codebase has grown organically from its start as xi-win. 2. The xi-editor project had other problems which I've written about extensively in my retrospective. 3. It's hard to compete against MS VS Code. When I started xi, the competitive landscape had a huge gap between performant and feature-rich but bloated editors. 4. We got funding for the font editor project.
    • fluffything 6y ago
      > 3. It's hard to compete against MS VS code. I agree, but as an emacs user that has tried it multiple times, I really don't "get it". The main thing that excited me about Xi wasn't Xi itself, but rather that its technology stack could be user to "build your own editor" using a solid foundation. That includes a more modern emacs, vi, vs code, or whatever you like.
• z3ncyberpunk 6y ago
  There are far more nonsense VC posts on HN than there are "rust this, rust that". IDK where you're seeing these rust posts everywhere