Is making your own UI library (without being dependent on a UI library such as Qt and GTK) difficult with Rust?
Yes, there's a reason nobody has built a good UI library for Rust yet.
I see, that is a bit of a shame.
I'd go on to add that this would be a daunting project to tackle in any language. It doesn't seem like it would be particularly more difficult to build a new UI library from scratch in Rust vs. any other language.
Given the number of Rust game engines out there, it's certainly capable of handling the raw event input and graphics output necessary..
If you want a feeling for how hard it can be have a listen to an expert talking about the issues and his approach to starting on the problem in Rust:
"Data Oriented GUI in Rust by Raph Levien - Bay Area Rust Meetup": https://www.youtube.com/watch?v=4YTfxresvS8&t=1865s
It sounds like too broad restrictions to me. If you're in JS on the web, the web api is your UI library. Even the opengl itself is a UI library provided by the GPU vendors. Vulkan, metal or D3D? They still are UI libraries abstracts over various silicon implementations.
If you're directly controlling voltage flowing into each pixels of the LCD, you're still using libraries provided by the CPU and the OS to interact with the IO devices.
On the other hand...
Back in the day we had PC's with CGA graphics. Later VGA/SVGA graphics. With these one could create graphics by writing appropriate bytes to appropriate areas of memory that were shared with the graphics adapters. Of course many 8 bit computers allowed for that as well. That is how people got GUIs into their games back then.
I once did some work for a company in the 1980's creating something that could be used by others to create "mimic panel" displays of chemical plant equipment status. It was rude and crude and lacking in much user input but worked well enough for it's intended task.
Recently I was thinking how I would do that today. On a typical Linux machine one has X Windows. Meh, throw that away. We can write pixel data straight into the frame buffer. Might not be fast an wizzy or very flexible but for a simple GUI of a few buttons and such it could work well enough for ones application.
Recently someone posted here a really nice looking font renderer crate. I though it would be great to have ago an using that to render into the frame buffer. Can't for the life of me remember what it was called now.
Sometimes that memory represented only a single row of pixels (cf. Atari 2600). You'd need to change it as the electron beam was scanning down the screen if you wanted anything other than vertical stripes.
It depends on what type of UI you want.
For example, games usually roll their own custom UI, because they already have sophisticated code for graphics rendering and handling input.
For a command-line application "UI" is a matter of parsing arguments and some terminal interaction, which isn't too hard to do.
OTOH if you want window-based GUI widgets, with proper system integration, flexible layouts, accessibility, etc. — that's a huge task that needs years of effort.
When you say that you mean like Rust is kinda too restrictive to do such things as I want in regards to developing my own GUI library?
I read @Hyeonu’s comment as suggesting that your original question is misguided. Depending on how you look at them, lots of things could be “UI libraries.” Unless you’re making your own hardware and writing your own OS, you’ll inevitably rely on one at least one of them (regardless of language choice).
So the proper question is which external code to rely on, rather than whether you can get away without any of it.