Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That kind of defeats the purpose?

Which purpose?



Speaking as an outsider, I have been watching Rust very closely for two reasons:

* I hope it will become a viable alternative to C/C++ for graphics programming. Unfortunately, last I checked as of ~6 months ago, Rust graphics libraries are still in their infancy.

* I hope it will eventually replace Electron as the go-to for multiplatform app development. IMO this cannot realistically be done by relying on native APIs / platform-specific tools like GTK, since we need something closer to functional reactive programming a la React/Svelte/SolidJS, with more emphasis on performance. If I wanted to build a GTK app, I would build a GTK app. See also [1].

I believe Rust has the potential to accomplish both goals, partially due to the design of the language, but mostly because I have faith in the very smart people who work on Rust to make good decisions in the long-term.

[1] https://raphlinus.github.io/rust/druid/2020/09/25/principled...


>I hope it will become a viable alternative to C/C++ for graphics programming

This already exists, it is called Free Pascal + Lazarus.


Care to elaborate? AFAIK C/C++ emerged as the alternative to Pascal way back when. No sense moving backwards--it's clear Rust is on track to displace several common uses for C/C++.


UNIX, like the browser for JavaScript, helped a bit the alternative to win against the competition.


What kind of graphics libraries were you looking for?


Just basic, stable support for OpenGL / Vulkan. My reading from ~January of this year was that there were several competing methods for graphics support in Rust. I tried a few and the boilerplate was quite a bit more than expected, and I was unsuccessful getting the available samples to run on my Linux machine.

Admittedly, I know nothing about what's actually going on behind the scenes when it comes to graphics + Rust. Just my first impressions as an outsider. I found the existing libraries quite difficult to get started with.

(I'm someone who doesn't know much Rust and is waiting for some of this functionality to mature -- someone already invested in Rust is certainly in a better position to take advantage of the existing graphics support)


Ok, in this case, I think the situation is fairly good. De-facto standard for raw Vulkan in Rust is Ash [1], and raw GL can be worked with GL-rs [2]. It's when you go higher levels where things start diverging more.

  [1] https://github.com/MaikKlein/ash/
  [2] https://github.com/brendanzab/gl-rs


Thanks! I think I overlooked those before--last time I got tangled up in gfx-hal. I'll give these a try!


There is nothing wrong with gfx-hal. I care deeply about it, and wgpu implementation is based on top. It's just for users who need portability and performance, while Ash gives you close to raw access to Vukan.


Of having a pure Rust based GUI without dragging in non Rust dependencies.


That's nice to have, but maybe not a central goal. It's worthwhile to have a library that's designed with Rust in mind and can take advantage of its features and idioms, even if it uses non-Rust libraries somewhere under the hood.

From the article:

> One strength is Rust’s wide “dynamic range” – the ability to describe application logic in high level terms while still being attentive to low level details.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: