5 ms·

This is one of the (several?) things that make me very worried about Rust long-term. I love the language, and reach for it even when it sometimes isn't the mos

by kelnos 7mo ago

This is one of the (several?) things that make me very worried about Rust long-term. I love the language, and reach for it even when it sometimes isn't the most appropriate thing. But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. When I used to write Scala, I accepted the fact that I don't have a background in type/set/etc. theory, and that there were some facets of the language that I'd probably never understand, and some code that others had written that I'd probably never understand. With a language like Rust, I feel like we're getting there. Certain GAT syntxes sometimes take some time for me to wrap my head around when I encounter them. Rust feels like it shouldn't be a language where you need to have some serious credentials to be able to understand all its features and syntax. On the other end we have Go, which was explicitly designed to be easy to learn (and, unrelatedly, I don't like for quite a few reasons). But I was hoping that we could have a middle ground here, and that Rust could be a fully-graspable systems-level language. Then again, for more comparison, I haven't used C++ since before they added lambdas. I wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts.

maccard 7mo ago
> I wonder if C++ has some hairy concepts and syntax today https://tartanllama.xyz/posts/cpp-initialization-is-bonkers/ https://tartanllama.xyz/posts/cpp-initialization-is-bonkers/
fridder 7mo ago
I wonder how Zig compares here
egorelik 7mo ago
Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.
- estebank 7mo ago
  I think there is: a schism. Another language, inspired, intelligible and interoperable with Rust, but with other goals, likely ease of use or surface simplicity. In my mind it would be pretty much the same as Rust, but whenever a compile error gives you a suggestion in rustc would instead compile (and at most be a warning in this hypothetical language). Migrating from Rust to this language would be changing a single setting in Cargo.toml. The other way around would be fixing a bunch of compile errors. You could use the entire crate ecosystem in a native way. This language could also serve as a test bed for features that might or might not be suitable for Rust. It can also have a more aggressive evolution schedule, meaning that it wouldn't be perma-1.x, so it can be bolder on what is attempted.
  - simonask 7mo ago
    I mean… Sure, if we’re just making stuff up, a compiler that can magically understand whatever you were trying to do and then do that instead of what you wrote, I guess that’s a nice fantasy? But out here on this miserable old Earth I happen to think that Rust’s errors are pretty great. They’re usually catching things I didn’t actually intend to do, rather than preventing me from doing those things.
    - nicoburns 7mo ago
      > But out here on this miserable old Earth I happen to think that Rust’s errors are pretty great. They’re usually catching things I didn’t actually intend to do, rather than preventing me from doing those things. As it happens, you are replying to the person who made Rust's errors great! (it wasn't just them of course, but they did a lot of it)
      - simonask 7mo ago
        I bow to them and thank them for their service!
  - teh 7mo ago
    There is precedent: with type checkers like pyright you can opt into specific checks, or have a basic, standard, strict setting, each expanding the set of checks done. How would dependencies work in this schism? E.g. if serde starts using named impls, do all dependencies have to use named impls?
jcranmer 7mo ago
> I wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts. … … … … Unqualified name lookup has been challenging in C++ since even before C++11. Overload resolution rules are so painful that it took me weeks to review a patch simply because I had to back out of trying to make sense of the rules in the standard. There's several slightly different definitions of initialization. If you really want to get in the weeds, starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust. C++ is the absolute most complex of any of the languages whose specifications I have read, and that's before we get into the categories of things that the standard just gives up on.
- jandrewrogers 7mo ago
  > starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust Annotations like std::launder, lifetime manipulation, etc solve a class of problems that exist in every systems language. They inform the compiler of properties that cannot be known by analyzing the code. Rust isn't special in this regard, it has the same issues. Without these features, we either relied on unofficial compiler-specific behavior or used unnecessarily conservative code that was safe but slower.
  - tialaramex 7mo ago
    > Rust isn't special in this regard, it has the same issues. This is both fundamentally true and misleading. Rust has to solve the same issues but isn't obliged to make all the same bad choices to do that and so the results are much better. For example C++ dare not perform compile time transmutations so, it just forbids them and a whole bunch of extra stuff landed to work around that, but in Rust they're actually fine and so you can just: const FOO: bool = unsafe { core::mem::transmute::<i8, bool>(2) }; That blows up at compile time because we claimed the bit pattern for the integer 2 is a valid boolean and it isn't. If we choose instead 0 (or 1) this works and we get the expected false (or true) boolean instead of a compiler diagnostic. C++ could allow this but it doesn't, rather than figure out all the tricky edge cases they just said no, use this other new thing we made.
PaulDavisThe1st 7mo ago
Reflection syntax (C++26 I think) has made my 30+ years-of-C++ brain melt. It's not insane, it's just ... melt-inducing.
- jandrewrogers 7mo ago
  Yeah, for me reflection and coroutines were the first changes to C++ where the implementation and use mechanics weren't immediately obvious by reading a few references. It requires a bit of proper study to wrap your head around it.
  - selfmodruntime 7mo ago
    I agree. It was the first time I actually thought 'who the hell writes code like this?'
Aurornis 7mo ago
> But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. Articles discussions new features always have difficult syntax. There have been proposals like this going on from the start. Fortunately the language team is cognizant of the syntax and usability issues with proposals. There have been a lot of proposals that started off as very unwieldy syntax but were iterated for years until becoming more ergonomic.
- kelnos 7mo ago
  I think it's more than the syntax, it's just the number of concepts you need to keep in your head to read a type signature, or a trait declaration, or whatever. There's only so much you can pack into a limited language before it becomes too much to keep in your head at once.
  - ifwinterco 7mo ago
    And then someone declares "this language is a mess! I'll take the good parts and create a new one without all this cruft!" and the cycle continues
  - bryanlarsen 7mo ago
    Most of the time over the past couple years when somebody complained about Rust getting a complex new feature, it was complex backend work that exhibited to users as the removal of restriction, making the language simpler. Example: async closures. A language that supports both async and closures but doesn't support them together is more complicated than one that supports async closures. This feels like it should end up similar. The driving desire here is the removal of a restriction, so hopefully it ends up as an end user simplification rather than complication.
staticassertion 7mo ago
I really wouldn't worry much. Over the last decade of rust, very few of the articles exploring new syntax have turned into anything controversial by the time they were merged (I can't even think of big rust syntax changes other than `impl T` in arguments etc). The singular example really is async/await and, having been quite worried about it / against it at the time, it was really nothing to be concerned with at all.
- jdonszelmann 7mo ago
  let-else was a more recently added new syntax
  - staticassertion 7mo ago
    Indeed, but it hardly seems controversial or major. It's sort of just an extension of existing syntax, similar to `impl Trait` in argument position.
jandrewrogers 7mo ago
> I wonder if C++ has some hairy concepts and syntax today Both better and worse. The current version of idiomatic C++ is much cleaner, more concise, and more powerful than the version of C++ you are familiar with. You don't need C-style macros anymore. The insane template metaprogramming hacks are gone. Some important things that were problematic to express in C++ (and other systems languages to be fair) are now fully defined e.g. std::launder. C++ now has expansive compile-time programming features, which is killer for high-performance systems code, and is more expressive than Rust in important ways. The bad news is that this was all piled on top of and in addition to the famous legacy C++ mess for backward compatibility. If you are mixing and matching ancient C++ with modern C++, you are going to have a bad time. That's the worst of all worlds. But if you are lucky enough to work with e.g. an idiomatic C++20 code base, it is a much simpler and better language than legacy C++. I've done a few major C++ version upgrades to code bases over the years; the refactored code base was always smaller, cleaner, safer, and easier to maintain than the old version.
- fc417fc802 7mo ago
  It's much simpler and better than it used to be but it's still pretty bad. As just one example off the top of my head consider the meaning of curly braces for initialization. There's several different things they can mean depending on the context. Good luck figuring out which set is currently in effect.
  - jandrewrogers 7mo ago
    The initialization situation in C++ is indefensibly broken. It is near the top of my list of things I hate about C++. You can mitigate it with some practices but that this is even necessary is a crime. Initialization is one of the most basic things in software development. How do you fuck it up so badly? On a day to day basis it doesn’t cause me issues but it offends me just on principle.
  - germandiago 7mo ago
    Use static analyzers and move on. Almost all the complaints I see about C++ nowadays are removed by max warning levels. Set them as error. Certainly initialization is the single most confusing feature in C++, I can give you that. But still doable with s few patterns to remember. And warnings always max level.
dap 7mo ago
Having used Rust professionally for six years now, I share your fear. Like many of the commenters below, coherence just hasn't been a big problem for me. Maybe there are problem spaces where it's particularly painful? How does the Rust language team weigh the benefits of solving user problems with new language features against the resulting increased complexity? When I learned Rust, I found it to be quite complex, but I also got real value from most of the complexity. But it keeps growing and I'm not always sure people working on the language consider the real cost to new and existing users when the set of "things you have to know to be competent in the language" grows.
- estebank 7mo ago
  You can look at the discussions in any of the language RFCs to see that increased complexity is one of the recurring themes that get brought up. RFCs themselves have a "how do we teach this?" section, that IMO makes or break a proposal. Keep in mind that as time goes on, features being introduced will be more and more niche. If you could do things in a reasonable way without the new feature, the feature wouldn't be needed. That doesn't mean that everyone needs to learn about the feature, only the people that need that niche have to even know about it (as long as it is 1) it interacts reasonably with the rest of the language, 2) its syntax is reasonable in that it is either obvious what's going on or easy to google and memorable so that you don't have to look it up again and 3) it is uncommon enough that looking at a random library you won't be seeing it pop up).
  - dap 7mo ago
    Thanks for the context. That makes a lot of sense! Those three constraints seem pretty important and a useful way to think about the problem.
deleted 7mo ago
[deleted]
BigTTYGothGF 7mo ago
> I wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts Yes, it's called "C++".
gedy 7mo ago
I wonder if Google's Carbon could fill that gap? https://en.wikipedia.org/wiki/Carbon_(programming_language) https://en.wikipedia.org/wiki/Carbon_(programming_language)
Ygg2 7mo ago
> But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. It's interesting to note the discrepancy between replies to this blog here and, say, lobste.rs (which is neutral to it). Here it's very concerned about complexity, while on lobsters it's mostly about needing this feature - yesterday.

by kelnos 7mo ago

maccard 7mo ago

> I wonder if C++ has some hairy concepts and syntax today https://tartanllama.xyz/posts/cpp-initialization-is-bonkers/ https://tartanllama.xyz/posts/cpp-initialization-is-bonkers/

fridder 7mo ago

I wonder how Zig compares here

egorelik 7mo ago

Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.

estebank 7mo ago
I think there is: a schism. Another language, inspired, intelligible and interoperable with Rust, but with other goals, likely ease of use or surface simplicity. In my mind it would be pretty much the same as Rust, but whenever a compile error gives you a suggestion in rustc would instead compile (and at most be a warning in this hypothetical language). Migrating from Rust to this language would be changing a single setting in Cargo.toml. The other way around would be fixing a bunch of compile errors. You could use the entire crate ecosystem in a native way. This language could also serve as a test bed for features that might or might not be suitable for Rust. It can also have a more aggressive evolution schedule, meaning that it wouldn't be perma-1.x, so it can be bolder on what is attempted.
- simonask 7mo ago
  I mean… Sure, if we’re just making stuff up, a compiler that can magically understand whatever you were trying to do and then do that instead of what you wrote, I guess that’s a nice fantasy? But out here on this miserable old Earth I happen to think that Rust’s errors are pretty great. They’re usually catching things I didn’t actually intend to do, rather than preventing me from doing those things.
  - nicoburns 7mo ago
    > But out here on this miserable old Earth I happen to think that Rust’s errors are pretty great. They’re usually catching things I didn’t actually intend to do, rather than preventing me from doing those things. As it happens, you are replying to the person who made Rust's errors great! (it wasn't just them of course, but they did a lot of it)
    - simonask 7mo ago
      I bow to them and thank them for their service!
- teh 7mo ago
  There is precedent: with type checkers like pyright you can opt into specific checks, or have a basic, standard, strict setting, each expanding the set of checks done. How would dependencies work in this schism? E.g. if serde starts using named impls, do all dependencies have to use named impls?

jcranmer 7mo ago

> I wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts. … … … … Unqualified name lookup has been challenging in C++ since even before C++11. Overload resolution rules are so painful that it took me weeks to review a patch simply because I had to back out of trying to make sense of the rules in the standard. There's several slightly different definitions of initialization. If you really want to get in the weeds, starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust. C++ is the absolute most complex of any of the languages whose specifications I have read, and that's before we get into the categories of things that the standard just gives up on.

jandrewrogers 7mo ago
> starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust Annotations like std::launder, lifetime manipulation, etc solve a class of problems that exist in every systems language. They inform the compiler of properties that cannot be known by analyzing the code. Rust isn't special in this regard, it has the same issues. Without these features, we either relied on unofficial compiler-specific behavior or used unnecessarily conservative code that was safe but slower.
- tialaramex 7mo ago
  > Rust isn't special in this regard, it has the same issues. This is both fundamentally true and misleading. Rust has to solve the same issues but isn't obliged to make all the same bad choices to do that and so the results are much better. For example C++ dare not perform compile time transmutations so, it just forbids them and a whole bunch of extra stuff landed to work around that, but in Rust they're actually fine and so you can just: const FOO: bool = unsafe { core::mem::transmute::<i8, bool>(2) }; That blows up at compile time because we claimed the bit pattern for the integer 2 is a valid boolean and it isn't. If we choose instead 0 (or 1) this works and we get the expected false (or true) boolean instead of a compiler diagnostic. C++ could allow this but it doesn't, rather than figure out all the tricky edge cases they just said no, use this other new thing we made.

PaulDavisThe1st 7mo ago

Reflection syntax (C++26 I think) has made my 30+ years-of-C++ brain melt. It's not insane, it's just ... melt-inducing.

jandrewrogers 7mo ago
Yeah, for me reflection and coroutines were the first changes to C++ where the implementation and use mechanics weren't immediately obvious by reading a few references. It requires a bit of proper study to wrap your head around it.
- selfmodruntime 7mo ago
  I agree. It was the first time I actually thought 'who the hell writes code like this?'

Aurornis 7mo ago

> But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. Articles discussions new features always have difficult syntax. There have been proposals like this going on from the start. Fortunately the language team is cognizant of the syntax and usability issues with proposals. There have been a lot of proposals that started off as very unwieldy syntax but were iterated for years until becoming more ergonomic.

kelnos 7mo ago
I think it's more than the syntax, it's just the number of concepts you need to keep in your head to read a type signature, or a trait declaration, or whatever. There's only so much you can pack into a limited language before it becomes too much to keep in your head at once.
- ifwinterco 7mo ago
  And then someone declares "this language is a mess! I'll take the good parts and create a new one without all this cruft!" and the cycle continues
- bryanlarsen 7mo ago
  Most of the time over the past couple years when somebody complained about Rust getting a complex new feature, it was complex backend work that exhibited to users as the removal of restriction, making the language simpler. Example: async closures. A language that supports both async and closures but doesn't support them together is more complicated than one that supports async closures. This feels like it should end up similar. The driving desire here is the removal of a restriction, so hopefully it ends up as an end user simplification rather than complication.

staticassertion 7mo ago

I really wouldn't worry much. Over the last decade of rust, very few of the articles exploring new syntax have turned into anything controversial by the time they were merged (I can't even think of big rust syntax changes other than `impl T` in arguments etc). The singular example really is async/await and, having been quite worried about it / against it at the time, it was really nothing to be concerned with at all.

jdonszelmann 7mo ago
let-else was a more recently added new syntax
- staticassertion 7mo ago
  Indeed, but it hardly seems controversial or major. It's sort of just an extension of existing syntax, similar to `impl Trait` in argument position.

jandrewrogers 7mo ago

> I wonder if C++ has some hairy concepts and syntax today Both better and worse. The current version of idiomatic C++ is much cleaner, more concise, and more powerful than the version of C++ you are familiar with. You don't need C-style macros anymore. The insane template metaprogramming hacks are gone. Some important things that were problematic to express in C++ (and other systems languages to be fair) are now fully defined e.g. std::launder. C++ now has expansive compile-time programming features, which is killer for high-performance systems code, and is more expressive than Rust in important ways. The bad news is that this was all piled on top of and in addition to the famous legacy C++ mess for backward compatibility. If you are mixing and matching ancient C++ with modern C++, you are going to have a bad time. That's the worst of all worlds. But if you are lucky enough to work with e.g. an idiomatic C++20 code base, it is a much simpler and better language than legacy C++. I've done a few major C++ version upgrades to code bases over the years; the refactored code base was always smaller, cleaner, safer, and easier to maintain than the old version.

fc417fc802 7mo ago
It's much simpler and better than it used to be but it's still pretty bad. As just one example off the top of my head consider the meaning of curly braces for initialization. There's several different things they can mean depending on the context. Good luck figuring out which set is currently in effect.
- jandrewrogers 7mo ago
  The initialization situation in C++ is indefensibly broken. It is near the top of my list of things I hate about C++. You can mitigate it with some practices but that this is even necessary is a crime. Initialization is one of the most basic things in software development. How do you fuck it up so badly? On a day to day basis it doesn’t cause me issues but it offends me just on principle.
- germandiago 7mo ago
  Use static analyzers and move on. Almost all the complaints I see about C++ nowadays are removed by max warning levels. Set them as error. Certainly initialization is the single most confusing feature in C++, I can give you that. But still doable with s few patterns to remember. And warnings always max level.

dap 7mo ago

Having used Rust professionally for six years now, I share your fear. Like many of the commenters below, coherence just hasn't been a big problem for me. Maybe there are problem spaces where it's particularly painful? How does the Rust language team weigh the benefits of solving user problems with new language features against the resulting increased complexity? When I learned Rust, I found it to be quite complex, but I also got real value from most of the complexity. But it keeps growing and I'm not always sure people working on the language consider the real cost to new and existing users when the set of "things you have to know to be competent in the language" grows.

estebank 7mo ago
You can look at the discussions in any of the language RFCs to see that increased complexity is one of the recurring themes that get brought up. RFCs themselves have a "how do we teach this?" section, that IMO makes or break a proposal. Keep in mind that as time goes on, features being introduced will be more and more niche. If you could do things in a reasonable way without the new feature, the feature wouldn't be needed. That doesn't mean that everyone needs to learn about the feature, only the people that need that niche have to even know about it (as long as it is 1) it interacts reasonably with the rest of the language, 2) its syntax is reasonable in that it is either obvious what's going on or easy to google and memorable so that you don't have to look it up again and 3) it is uncommon enough that looking at a random library you won't be seeing it pop up).
- dap 7mo ago
  Thanks for the context. That makes a lot of sense! Those three constraints seem pretty important and a useful way to think about the problem.

deleted 7mo ago

[deleted]

BigTTYGothGF 7mo ago

> I wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts Yes, it's called "C++".

gedy 7mo ago

I wonder if Google's Carbon could fill that gap? https://en.wikipedia.org/wiki/Carbon_(programming_language) https://en.wikipedia.org/wiki/Carbon_(programming_language)

Ygg2 7mo ago

> But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. It's interesting to note the discrepancy between replies to this blog here and, say, lobste.rs (which is neutral to it). Here it's very concerned about complexity, while on lobsters it's mostly about needing this feature - yesterday.