upvote

points

by nmilo8 hours ago |
comments
upvoteby staticassertion6 hours ago|
next
[-]
My very weak understanding is that a lot of the C/C++ libraries heavily leverage concepts like inheritance that don't map well to Rust, and so a lot of the GPU work has been "how do we actually make this an idiomatic API?" and that has required more experimentation.

AFAIK people 100% are using other libraries for UI, but often use a macro or something to force Rust to behave in a way that those libraries expect.

I haven't read about this in literally years, but that's my recollection.

reply
upvoteby zem6 hours ago|
prev|
next
[-]
yeah, it's fine that people are experimenting with new gui toolkits from scratch but I wish gtk integration got a lot more love.
reply
upvoteby duped5 hours ago|
prev|
next
[-]
GUI is much more than just cross platform windowing. Which fwiw, is a mostly solved problem in Rust - there's not a bunch of reimplementation or instability. The ecosystem is solidified behind winit (*).

Also, we don't have good cross platform desktop GUI libraries in C. That's why everyone started using Electron.

(*) with some small exceptions

reply
upvoteby jauntywundrkind8 hours ago|
prev|
[-]
Aside from Rust being better (impl is such a great decoupling, fearless type safety), there is afaik nothing one tenth as useful and good as cargo & is crate ecosystem (docs rs, crates.io, and all the packages).

I find it odd the broader hacker community feels the need to requestion and cross-examine every choice for using rust. Like, no other language has such great just works ergonomics, with a solid language, fantastic tooling, excellent packages that gives it a just works the first time cross-platform joy. Why does every thread have to spawn a brand new unsupported whinge throwing dirt at what seems like such an obvious enjoyable choice?

reply
upvoteby saghm7 hours ago|
parent|
next
[-]
I think you might be misunderstanding the parent comment. It sounds to me like they're arguing in favor of wrapping C GUI library when writing a GUI app in Rust, not avoiding Rust entirely. As far as I can tell, they're arguing for writing new stuff in Rust that happens to be re-using some components that aren't in Rust. I'd argue that's entirely in the spirit of Rust; kind of the whole point is that you can put a hard boundary on where the unsafety lies and make everything safe outside of that boundary. When I use a Vec or a HashMap, there's unsafe code under the hood, but it doesn't stop me from writing my own code without needing to dip into unsafe at all, and there's no fundamental reason why the same couldn't be done by wrapping Qt or Gtk on Linux or Cocoa or MacOS.
reply
upvoteby piker6 hours ago|
parent|
[-]
Qt is great, but it's a commercial license.
reply
upvoteby pixelesque4 hours ago|
parent|
[-]
Not if you dynamically link it. LGPL.
reply
upvoteby piker4 hours ago|
parent|
[-]
Is it that simple?
reply
upvoteby nmilo7 hours ago|
parent|
prev|
next
[-]
Ah, I meant to reply to https://news.ycombinator.com/item?id=47003058. Never questioned the use of Rust, only the need for the entire windowing stack to be in Rust (that blog post shows a case where it bit them)
reply
upvoteby drnick16 hours ago|
parent|
prev|
next
[-]
One could argue that Rust isn't well suited for GUI development at all, where class-based OOP really shines.

Then there is the issue that the Rust community likes to rewrite classic C programs because of "memory safety" and "modern tooling," but really just focuses on the easy 80% of the work. It feels like these rewrites are more done to gain popularity on GitHub than anything, as they most often remain incomplete and never replace the original implementation.

Finally there is the GPL to MIT licensing issue, on which much has been said already.

reply
upvoteby shdh7 hours ago|
parent|
prev|
[-]
Rust build times are not an enjoyable part of its DX
reply