7 ms·

It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly

It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

DonaldPShimoda 4y ago
It's amusing to me that many of the people who complain about the aesthetics of Rust's syntax are quick to also say bad things about, like, Haskell, or Lisps, or other languages with comparatively low syntactic overhead. I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain. I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.
- flohofwoe 4y ago
  Typescript and Zig are two other languages that look vaguely C-like (even though they are on two opposite ends of "C like"), but both are a whole lot easier on the eyes than most Rust code. C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code. OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases: https://github.com/makepad/makepad https://github.com/makepad/makepad
- throwawaymaths 4y ago
  Languages on the two ends of the spectrum are "not that great", IMO. Lisp is awful because even though there are very few greeblies, it introduces a TON of cognitive overhead, because you need to be constantly thinking about what something is, because the layout is TOO uniform. Rust on the other hand has a lot of greeblies and you have to remember what it is and what they do. For example macro attributes (and all their hidden effects) as well as the turbofish. Even some things like -> for the function body are simply unnecessary.
foldr 4y ago
One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this: var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...} This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some abomination like this: let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ]; Sure, it's more explicit. But even if I add a type annotation to 'foo' specifying the array type, I still have to repeat MyStruct for every member.
- guipsp 4y ago
  Do you mean the vec! macro?
  - foldr 4y ago
    It doesn't let you drop redundant struct tags, as far as I can tell.
    - tialaramex 4y ago
      I think you're right, although mentioning a macro does suggest another option here, you could write a macro which transforms [{foo1, "bar1", baz1}, {foo2, "bar2", baz2}] into the named structure version. Since it's a macro there's no impact on runtime performance, but on the other hand it's more work to debug it. Learning declarative macros in Rust is much nicer and safer than learning C macros, but nowhere near as powerful as Rust's horribly unsafe proc macros.
- rom-antics 4y ago
  If you want compact, use an array of tuples: const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...]; for (str1, num, str2) in &foos { // ... } For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.
jasonjmcghee 4y ago
I'm going to assume, based on when he said "As a slightly more serious and useful exercise" and then proceeds to remove each piece of the code that's intentionally there for performance and safety, that the whole post is satire?
- munificent 4y ago
  The second sentence of the post is the thesis: "I think that most of the time when people think they have an issue with Rust’s syntax, they actually object to Rust’s semantics." By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.

DonaldPShimoda 4y ago

It's amusing to me that many of the people who complain about the aesthetics of Rust's syntax are quick to also say bad things about, like, Haskell, or Lisps, or other languages with comparatively low syntactic overhead. I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain. I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.

flohofwoe 4y ago
Typescript and Zig are two other languages that look vaguely C-like (even though they are on two opposite ends of "C like"), but both are a whole lot easier on the eyes than most Rust code. C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code. OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases: https://github.com/makepad/makepad https://github.com/makepad/makepad
throwawaymaths 4y ago
Languages on the two ends of the spectrum are "not that great", IMO. Lisp is awful because even though there are very few greeblies, it introduces a TON of cognitive overhead, because you need to be constantly thinking about what something is, because the layout is TOO uniform. Rust on the other hand has a lot of greeblies and you have to remember what it is and what they do. For example macro attributes (and all their hidden effects) as well as the turbofish. Even some things like -> for the function body are simply unnecessary.

foldr 4y ago

One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this: var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...} This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some abomination like this: let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ]; Sure, it's more explicit. But even if I add a type annotation to 'foo' specifying the array type, I still have to repeat MyStruct for every member.

guipsp 4y ago
Do you mean the vec! macro?
- foldr 4y ago
  It doesn't let you drop redundant struct tags, as far as I can tell.
  - tialaramex 4y ago
    I think you're right, although mentioning a macro does suggest another option here, you could write a macro which transforms [{foo1, "bar1", baz1}, {foo2, "bar2", baz2}] into the named structure version. Since it's a macro there's no impact on runtime performance, but on the other hand it's more work to debug it. Learning declarative macros in Rust is much nicer and safer than learning C macros, but nowhere near as powerful as Rust's horribly unsafe proc macros.
rom-antics 4y ago
If you want compact, use an array of tuples: const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...]; for (str1, num, str2) in &foos { // ... } For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

jasonjmcghee 4y ago

I'm going to assume, based on when he said "As a slightly more serious and useful exercise" and then proceeds to remove each piece of the code that's intentionally there for performance and safety, that the whole post is satire?

munificent 4y ago
The second sentence of the post is the thesis: "I think that most of the time when people think they have an issue with Rust’s syntax, they actually object to Rust’s semantics." By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.