Hacker News Reader

Comment by TobyTheDog123 | Hacker News Reader

This may not be the message of the article but as a side-rant:

I really don't understand the use-case for a Rust-based GUI.

Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.

I understand that not every UI needs to be a cross-platform blah blah blah written in TypeJavaReactScriptJS, or a pixel-painted canvas written in Flutter. I also understand there's a use-case for one-off UIs that may not target a browser.

Let's compare it to something like Golang. Fast compile times, similar libraries, garbage collection -- it seems like something more suited for UIs where there are usually a lot more iterations. Worse performance for sure, but Rust also seems more-than-overkill in that regard for the UI use-case.

View on HN

From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll probably hate golang.

We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.

So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.

If you're going to use electron and all the bad that comes with it, why not just use typescript though?

I love typescript, but hate the JavaScript parts of it.

With a good linter config set super strictly, you can make Typescript feel like you're barely writing Javascript at all.

Any Javascript devs will probably hate working like that because now they're forced to write types for absolutely every single thing, but to me it felt like Javascript was finally fixed.

Just banning things like "any" and enforcing proper nullability makes up for a lot of Javascript problems.

This is the worst part of JS. To make it workable u have to:

- setup linting (which is awful and annoying) - formatting - use typescript

and then maybe u have a usable work environment. Rust just does that out of the box.

I disagree - Javascript's issues are not just its lack of type safety.

Even with Typescript you're dealing with the disastrous state of NPM/configuration/linters/formatters/libraries -- all of which are firmly Javascript-esque plagues (though not exclusively Javascript plagues).

Because even though typescript improves on Javascript and even golang, it still is much less nice than Rust.

> I really don't understand the use-case for a Rust-based GUI.

For people already writing things (libraries, cli's etc) in Rust who want to add a GUI while staying with the language. No great mystery.

As for a business case, aside from individual developer taste/preference, it's hard to see that there is one outside of niches. System76 found a case for it with their DE. I think there might be a strong case for lightweight Rust GUI frameworks like egui for embedded device displays.

But for mainstream web / desktop / mobile apps? I can't at the moment see what the point would be.

Things are a bit different in certain graphics app domains, where you need to create complex tools for professionals (think of image editing, 3D modeling, video processing, CAD, game engines, etc.) The users demand all kinds of functionality that requires squeezing the CPU and GPU to the fullest extent. And you have to do this while designing a complex UI with numerous complex controls, and it also needs to be butter-smooth. (Also note that the majority of the low-level APIs/drivers you need to use are in C/C++!) In that case, using languages like Go/Java/Javascript creates more problems than it solves (even if you only write the core in C++/Rust and use bindings.)

> Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.

What about a vector or image editor, a 3D DCC etc?

These are prime example for desktop apps where existing solutions are 100% written in C++.

That's stuff where Rust would be a better alternative if you started work on an app like this today.

In VFX there is a whole initiative by the ASWF to wrap the stack in Rust for starters and possibly have new additions written in that language instead of C++ in the future.

And compiling to WASM and being able to run in a browser (even if only as a single canvas element with all applying limitations) is a great plus.

Yeah it seems to be a pretty niche use case. The learning curve for Rust is simply too high (my GOD the syntax). You can just get much more done, in less time with a web framework.

I looked into Rust for writing games (including the UI frameworks), but found that the power it provides isn't really worth all the mental overhead. Most games don't really need that much power, particularly if you are using non-realistic graphics. In the event that you do actually need extra optimization, most engines let you hook down into C++ for raw performance.

> The learning curve for Rust is simply too high (my GOD the syntax)

The syntax isn't even close to being a difficult part of the language, and it's something you get used to very quickly. The Rust syntax just isn't readable for people who don't yet know Rust, just like I find C++ difficult to read.

> You can just get much more done, in less time with a web framework.

Sure, you can also get it running even quicker in Python. But when it comes to maintenance I prefer something where the type system wasn't just slapped on top. That said the web does feel like the only fully-featured and truly cross-platform GUI at the moment.

This is a matter of familiarity. For example, Golang is claimed to have simple syntax, but I find Golang's syntax much harder to read than Rust. The fact they avoided keywords and symbols like a plague caused that now e.g. function signatures are mostly names, spaces and parentheses, and the meaning of them depends on their relative positions, which is something I'm not used to.

I guess if I wrote / read Golang sources more frequently, that would become a second nature and would not slow me down.

> This is a matter of familiarity

No it is not. Or at least not for everyone.

I have learned several languages more unfamiliar to me than Rust (pure functional, logic, stack-oriented,etc), but none has given me the difficulties Rust has. Also (only my sample of course, but there are no reliable stats) no-one I personally know who has gone through the Rust book has continued with Rust. The Rust Foundation hasn't made 'flattening the learning curve' one of its 2024 goals because people don't find Rust harder than other languages. Many just do.

A false universal doesn't become true through brute repetition.

can i ask what kind of things you specifically found confusing about the syntax?

I don't have a problem with Rust syntax. Actually I can't imagine any developer with more than a year or two's experience has much trouble with any language syntax (unless it's something truly weird like APL). After a few days use you barely notice surface details anyway - it's just one possible representation of an AST.

My problem with using Rust is the way its complexity creeps into everything. There are large numbers of stdlib utility traits whose idiomatic use you have to remember to read almost any real world code. There's hardly a Rust library in common use that isn't a huge sprawling mass of over abstracted generics and macros. Even command line parsing is made to be a vastly complex endeavour. There are admittedly sugary niceties (eg derive attributes) that can make use of many of these libraries tractable for easy cases. But overall any substantial Rust program makes cognitive and memory demands on the programmer far in excess of what most languages require for the equivalent in my experience.

I can agree with that, I don't like overly abstract stuff either. That said in my projects I'm in control of the code and so I tend to avoid traits where they're not really necessary, I find Rust very pleasant to use that way and the compiler messages are simply outstanding. Often lifetime annotations can be replaced with heap allocations, which isn't always that efficient but it's a damn fast language and often you're not even going to measure a difference.

> Even command line parsing is made to be a vastly complex endeavour.

Yes, I even wrote a library for that once but then realized it only complicates everything and adds limitations. Nowadays I just do that by hand. For one it's guaranteed to be shorter than any parsing library, but also it's a good opportunity to think about what kind of arguments I need and in which form. And copy-pasting the parser from the previous project and adapting it is quick & easy.

Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is just stubbornness (because I find it hard), but some practical (performance, WASMability etc). I do like the way the type system makes it seem like things snick precisely into place when you get things right.

My beef (such as it is) is that I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. It takes me probably 4x as long to do anything compared to any other language I've used (and although I'm not a talented programmer, I am a polyglot).

Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.

> I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming.

I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other languages. I don't mind the compilation speed as much as some people seem to do, but the learning curve definitely is a problem.

Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there, the borrow checker almost never stands in the way. And realizing I can move owned stuff around cheaply instead of copying/referencing was also another huge enabler.

However I can imagine when Rust borrowing rules can be a huge pain. This happens when you expect to continue using the same style of programming that relies on big piles of (often cyclic) object graphs built with references/pointers, shared mutability, heavy (runtime) indirection and inheritance. A style that is so prevalent in OOP projects written in Java, JS, Python. I don't like this style at all, and always tried to avoid it even when coding in those languages, because I believe it causes more harm than good. Rust will simply force you to unlearn it. And some people won't need to unlearn much, and some will have to unlearn a lot. Changing habits is always pain.

I think it should be simply considered a different paradigm.

> I think it should be simply considered a different paradigm.

I addressed this above and believe it to be an unconvincing explanation of Rust's difficulty. Many polyglot programmers comfortable with, and experienced in, switching (and learning new) paradigms, still find Rust more difficult than other languages they have learned. In my experience most just give up. I haven't, but neither have I become remotely productive in the language.

Of course my experience is just one person's sample. There isn't much else to go one. But the Rust Foundation clearly agrees with me, given its 2024 roadmap. In our view, Rust is hard to learn and use, more than most languages, and problematically so for many.

How come Rust appears at the top of most loved languages in the SO survey so many years in a row? And doesn't even make into the "most dreaded" list at all (when many simpler languages do make into that list)?

Also, there aren't any other mainstream languages with borrow checker at the moment. The problem with Rust is that it introduces many novel ideas, not just some old ideas wrapped in a different syntax (e.g. like Kotlin or Swift). They need time to get into developers heads. Similarly it took many years to accept some ideas from FP into mainstream languages, and people were even debating if Java needed lambdas.

And BTW: I didn't find Rust harder to learn than, e.g. Python or Scala... Scala was kinda fun, but FP required similar amount of mind-bending as lifetimes in Rust, and Python was just purely frustrating.

> How come Rust appears at the top of most loved languages in the SO survey so many years in a row? And doesn't even make into the "most dreaded" list at all

Because these two lists are mutually exclusive.

On the survey they ask:

* Do you use X today?

* Do you want to continue to use X in the future?

"Most loved" means "the ratio of yes/yes answers is high", and "most dreaded" means "the ratio of yes/no answers is high."

Rust wins "most loved" because many users say yes/yes, and few say yes/no.

If so few people say yes/no then this means to me that either the difficulty is not really as bad as some people try to paint it here (under assumption people don't want to continue using a language that is frustrating), or that indeed the difficulty level might be high but developers get a lot in return, so it is still worth to pay that price and continue using Rust, which means - maybe it is difficult, but it is still productive.

It is very hard if even possible to objectively assess the difficulty of the language, because difficulty is inherently subjective and depends heavily on prior experience. The fact that there are many people who claim to be more productive in Rust than e.g Python or Java, but at the same time many others that don't share that opinion, IMHO supports my claim this is mostly a matter of a paradigm shift.

Also I noticed many developers somehow don't count the difficulty to fix bugs towards the difficulty of the language. And maybe that's also an explanation why we end up with so vastly different opinions.

However often you inform someone that they are wrong about what they found difficult, it will not thusly become true. Your brutish & obdurate insistence is only boring.

The difference between what you and I are claiming isn't in the substantive content, it's that you, Shiny Happy Rust Person-style (exemplifying what many of us find so ugly and bullying about the much-vaunted "Rust community") insist on universalising your personal experience.

I've already told you that novelty is nothing whatsoever to do with why I find Rust difficult. It has few novel concepts, and they are simple enough. Note that I never mentioned the fucking borrow checker. Now fuck off. I've blocked you anyway.

Reply on news.ycombinator.com