Rust Additions for GCC 15 Bring Support for If-Let Statements
24 comments
·March 24, 2025Corrado
Vurdentium
Do they deliberately make Rust so difficult to read or is it an unfortunate consequence of its complexity?
maggit
It's more a matter of your personal preference and previous exposure to different languages. The way Rust reads is one of its super strengths in my book. I also really enjoyed Standard ML in university, and Rust picks up some of that (via OCaml).
baq
Rust is a low-level ML variant with curly braces syntactically.
dontlaugh
It’s just familiarity. I find it much easier to read than C++.
wruza
>Option<T> option
>match option
>if option.is_some()
>Neither of these options is particularly appealing.
There’s the answer. The new syntax is just particularly appealing.
Does “if let some of x be assigned an option:” make better sense and sound greater than “match option, some of x:” and “if option is some:”?
Defletter
It's certainly cleaner, but my immediate thought when reading was "that's a compile error" because it looks like it's declaring a variable with a type mismatch. This is where, in other languages, the "case" keyword (or similar) comes in handy (eg: Dart's if-case syntax[1]), except Rust doesn't have that because of its headlong pursuit of 'conciseness'.
rowanG077
No doubt there are some things that are hard to read in Rust. In the link posted everything seems very straightforward and should make sense if you know a c-like language.
timeon
Which part in that link are you finding difficult to read?
First example with `match` seems to me already more readable than `switch` statement with breaks.
juped
Somewhere in between. There actually is a level of demand for languages which are annoying to use; whether this is annoying syntax or annoying semantics isn't much of a distinction, they dovetail. But more than that, there's demand for ML clones (but with curly braces), and neither ML nor generic-curly-brace is the strongest foundation to build readability on, unfortunately.
survirtual
Short answer: It is difficult because you aren't familiar with it, and your brain is still wired for memory-unsafe or GCed languages. But it is actually easier to read than most other languages when you understand it and how to navigate it.
When I first started learning Rust several years ago, I shared your viewpoint. With a heavy preference for C++ syntax, I thought Rust looked atrocious.
Then I learned it. I got good with it. I got comfortable with it. I switched from VS Code based IDEs to vim, then to IDEs with vim bindings (trying Zed now). Now, Rust reads like a dream -- aside from lifetime specifiers, which I think could be much smarter than they are now.
Anyway, it has superior pattern matching and code searching. snake_case is easier to navigate than camelCase or PascalCase. Keywords are short and easily recognizable. Branching logic is much, much easier to follow. Error handling is explicit and also easier to follow (and I started out really missing try-catch). Code gen with macros eliminates a lot of headaches. A 1st class package manager that is fast & can be easily inspected, that seamlessly integrates into the code...the list goes on.
The point is, it is a paradigm shift that doesn't hide much of anything away. When you consider there is no GC and you are in full control of memory, that there are strict syntax and styling rules that make the global Rust codebase universally accessible, once you switch to it you find yourself wishing everything was written in Rust. That is why people using it want to rewrite everything, even well established packages. A Rust-only codebase is buttery smooth.
jamincan
In general, I find Rust very readable. The areas I do find I struggle are generics and lifetimes, and I don't think it's a feature of Rust syntax that makes me struggle and is instead the fact that people tend to use non-descriptive names for lifetimes or generics. It's hard to pick apart a trait that has four generics name T, U, V, and W, or lifetimes 'a, 'b, and 'c.
Usually people will try to make it the first letter of something meaningful, but it is still much harder to parse.
My own preference is to use more descriptive names except in trivial cases. Having the lifetime mirror a struct member name or a parameter name is really helpful for understanding them, in my opinion.
weakfish
Although I disagree with your point made, I appreciate you taking the time to write a well-thought out reply.
pjmlp
On a side note, gccgo seems to be on the route to follow gcj footsteps removal from GCC, left to stagnate on 1.18 version without any clear roadmap if it will ever be touched again other than minor bug fixes.
Kind of ironic now with Cobol being added in GCC 15, joining Modula-2, D, Rust, Fortran, Ada, C, C++ collection of frontends.
null
This sounds like good progress for getting Rust into more places. I had no idea that this type of thing was not supported in Rust-GCC.
BTW: Here's a good reference to the differences between "if" and "if let" - https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...