Rust's Ugly Syntax

https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

by matklad • 3 years ago

159 229 3 years ago

matklad.github.io

Rust’s choice of sigils is aesthetically displeasing. Double colons (::) and angle bracket generics are ugly. Unmatched apostrophes is jarring to those used to them being used for strings or character literals. It was an unforced error to imitate C++, which was forced to use those characters due to backwards compatibility with C and the C preprocessor. A new language doesn’t have to use those characters. For example, the D language uses the dot as a path separator for modules, namespaces, templates, etc. as do other languages like Python.

HideousKojima• 3 years ago

I like angled brackets for generics but hate double colons. I assume it's because I'm coming to Rust from C# though? I wonder how C++ devs learning Rust feel.

kibwen• 3 years ago

It was an unforced error to imitate C++

Rust spent enough of its weirdness budget on new semantics. I may not be a fan of C++-style syntax, but if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.

arthurcolle• 3 years ago

This is almost overly permissive... Yeah sure it looks the same but the semantics are so different that the statement seems... wrong

lmm7• 3 years ago

if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.

I wonder how well that's worked out for them. My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++.

jb19912• 3 years ago

Angle brackets aren't that uncommon, are they? Swift is a modern, elegant language that uses angle brackets for generics. Fortunately it uses the period instead of the double colon (thank goodness for that!) but I don't see anything ugly about brackets.

ssokolow13• 3 years ago

It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in

let foo.iter().map(|x| x*2).collect::<Vec<_>>()

If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts.

They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with

https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...

WalterBright5• 3 years ago

It would have worked in C++ to use the . for them, too.

kazinator8• 3 years ago

Unmatched apostrophes is jarring

Welcome to Lisp! 'x means (quote x)

'(+ 1 2) evaluates to (+ 1 2)

davidkunz2• 3 years ago

I don't know if it's just me, but find angle brackets really hard to read. Many times I just miss the ending one, because they have the same height as normal characters, so they don't stand out.

zozbot2346• 3 years ago

That's a font issue. In proper type setting, angle brackets are different from normal less/greater than characters. An IDE with good in-built parsing could use variant forms for <> characters as used in generics, as opposed to relational operators.

puffoflogic2• 3 years ago

<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value syntax, which is great in dependently-typed languages but bad elsewhere. [] is already used for slices, albeit in a different way; and C should be objection enough if you want to make types look like values. {} is a nonstarter because it leads to ambiguity between return type and function body, and in an everything-is-an-expression language, once again we are back at types-look-like-values. There are no more matched pairs left on an ANSI keyboard.

Personally, while I hear you that :: is ugly, I do really like being able to distinguish module paths from value paths at a glance. And when looking for an alternative, we once again run into other characters already having far more familiar conflicting uses, or just being too weird. (E.g., # or @ could have been used, but that's probably worse than ::.)

zozbot2346• 3 years ago

To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.

nneonneo2• 3 years ago

And that's why we have Unicode!

    Vec⟪u8⟫
    Vec｢u8｣
    Vec⟦u8⟧
    Vec༼u8༽

I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!

Ferret7446• 3 years ago

Nah, <> are much worse, because they are syntactically binary operators.

estebank8• 3 years ago

[] are already taken by the slicing syntax, but if that wasn't the case you could have something like vec@2 and vec@{end - start} for that, which would open them up for generics. I'm pretty sure the main reason to choose <> was familiarity above all else.

edflsafoiewq2• 3 years ago

<> are obviously already used for less than/greater than, so they're disqualified too by this logic.

If you broaden your viewpoint, [] is the same thing for arrays and generics. A generic function is a family of functions parameterized by types; an array is a family of values parameterized by 0..n; [] selects one member of the family. In fact in math subscripting is already a common notation for the parameter of a generic.

Same for paths using dot, it's just member access on a module object. In languages like JS or Python it's literally just normal runtime member access. In Zig it's also just normal member access on a comptime object.

rhaway84773• 3 years ago

The exclamation mark choice seems poor as well. It’s something one would associate with something extraordinary, like an exception.

Seeing it in code all over (as a beginner…I’m sure after a while you get used to it), it screams danger to me every time I encounter it in code.

ssokolow13• 3 years ago

It means "DANGER: This may hide an early return or other things which violate the expectations for how control flow works."

jeremychone3• 3 years ago

I had the same initial opinion about the '.' Vs. ':' for module separation. Why add weight to make this distinction?

However, after over a year of coding Rust every day, I now really appreciate the distinction. It's an effective way to give a meaningful context point at a very low cost.

I was wrong again! Which has been a consistent pattern with my initial Rust appreciations.

29athrowaway2• 3 years ago

It would be much simpler to not think about error handling at all,
and let some top-level
try { } catch (...) { /* intentionally empty */ }
Much better now!

jrk• 3 years ago

I think you missed the implied wink. This post is not arguing for throwing away all performance and safety, it is showing how “ugly syntax” is actually mostly inherent complexity from trying to be safe and fast.

ben0x5395• 3 years ago

Like, all the syntax does something that contributes to being safe and fast, but that doesn't mean there couldn't be a completely different notation for all of that. Maybe there is nothing that would make everybody happier, but for any given person unhappy with Rust syntax, there's probably a bunch of tweaks you could do to make it nicer for them.

For example, in

    pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {

for me it's really unpleasant that there is so much stuff between the function name and the names of the parameters. It's a bit nicer with already-a-Rust-feature where-clauses like

    pub fn read<P>(path: P) -> io::Result<Vec<u8>> where P: AsRef<Path> {

but if nothing else I think that makes a mess of the indentation if you linebreak anywhere in that line.

C++ avoids this by just yanking all the extra bits at the very start of the declaration, so we could copy that (without going all the way into C++ caricature):

    for<P: AsRef<Path>>
    pub fn read(path: P) -> io::Result<Vec<u8>> {

This addresses my specific complaint, but is probably worse for other people. Who knows.

As another example, the whole business with explicit Result types and the early-return question mark is basically isomorphic to checked exceptions, which may or may not be syntactically lighter/more pleasant. Would Rust enthusiasts prefer that? Probably not. Would it make the language more approachable to people coming from some Java ecosystem? Maybe? Would it be worth it? No idea.

agentultra• 3 years ago

It’s still ugly! There’s nothing wrong with that. Everyone will have different opinions on these things. Bike shedding will probably never go away.

The semantics are what matter (at least in most programming languages)!

To me, syntax wise, I just can’t stand inline type definitions. CrabML becomes close to what I can grok syntax-wise. I spent many years with C++ and I can read TyoeScript… but to me they’re examples of bad syntax, not role models.

However if you read A Logical Approach to Discrete Math or Programming in the 1990s you’ll know just how syntax matters… most programming languages can’t even reach this level of which is why I think semantics are more important.

stephc_int133• 3 years ago

Yes that is ugly and no complaining about syntax peculiarities is not bike shedding.

Code aesthetics is directly related to its readability and to programmers quality of life.

Code should be made as simple to read as possible, the writing part is less important.

MrJohz2• 3 years ago

It seems obvious that bad syntax harms readability, in that it's very easy to construct an example of a programming language that is truly unreadable (use commas to indicate generics, everything must be upper case, backslash to call functions and pipe to separate arguments, the letter `H` is used to start a class declaration, etc - the Intercal of syntaxes).

But the reverse seems more difficult to argue: that there is some ideal syntax that is objectively more reasonable than all other syntaxes. I have preferences (do/end blocks feel like unnecessary noise, I like my types to be written inline in my functions, angle brackets feel right for generics), and some of them even have a veneer of logic behind them (significant indentation is a nuisance when I want to paste a block of code that has the wrong indentation). But clearly other people have different preferences, because they keep on designing languages that don't fit my ideal aesthetics.

The other side of this is that the more I write different languages, the less important syntax becomes. The places where I appreciate the syntax of a particular language are usually because the syntax fits particularly well with the language's semantics, rather than because the syntax itself is good or bad. Partial application in ML-family languages is syntactically very neat, but I don't feel the need to remove parentheses from Javascript because of it. What I really like is partial application, and using space as the function application operator works well with those semantics.

stephc_int133• 3 years ago

I think that many recent or a bit less recent languages uses too many symbols instead of words.

Words are less ambiguous and cleaner.

rascul• 3 years ago

it's very easy to construct an example of a programming language that is truly unreadable

I submit for your consideration Brainfuck and Whitespace. There are others but these two came to mind first.

https://en.wikipedia.org/wiki/Brainfuck

https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

pornel• 3 years ago

"Make it simple" is easy to throw around, but it's almost meaningless. Perception of simplicity and readability is incredibly subjective and dependent on previous experience. Beyond that it also depends on what goals the language has, because "simple" from one point of view can be oversimplified and unclear from another POV.

Rust is a systems programming language concerned with several low-level details. Programmers aren't reading Rust code for entertainment, but need to be aware of things like ownership, mutability, lifetimes, trait bounds, dynamic dispatch, and so on. Beyond being eye-pleasing, Rust also needs to be locally explicit to communicate costs, limitations, and unsafety of the code.

As the article shows, beyond just bikeshedding which ASCII sequence you use for what, the aren't many ways to simplify the syntax that don't involve hiding information or changing language semantics that could worsen performance or create unpredictability.

stephc_int133• 3 years ago

Simplicity is partially in the eye of the beholder, I agree.

And there is always a subjective part about any design decisions, but overall there are better designs and worse designs.

And concerning programming language syntax, I tend to prefer a bit of verbosity over any terseness / compactness.

I prefer Java/C# style over Perl/Sed. And I think that modern system programming languages tend to drift a bit too much towards the Perl style.

Writing powerful but unreadable on-liners should be considered harmful.

aniforprez• 3 years ago

This... reads like a joke post

girvo• 3 years ago

I mean the post itself basically says as much. Not quite joking, but sarcastic, and to demonstrate that (as far as the author is concerned, I have no strong opinion personally) the complaints about Rust's syntax are not actually due to the syntax, but the semantic features that necessitate some kind of syntax to make them work.

It's a bit of a straw-man, of course, but it's an interesting idea that made a couple things a bit clearer for myself.

CGamesPlay2• 3 years ago

The C++ sample is definitely a strawman: you allowed Rust to `use std` but C++ was not permitted `using namespace std`. Still ugly, less so. And further, I think your "deoptimized" Rust sample should be the headliner, since you point out that the Rust sample sacrificed readability for performance reasons.

The next noisy element is the <P: AsRef<Path>> constraint.

Should be replaced with `fn read(path: impl AsRef<Path>)`

We’d have to use some opaque Bytes type provided by the runtime.

A less joke example might be to have `pub type Bytes = Vec<u8>` as a secondary declaration.

I guess the rest of the post is just hyperbole. Next time, take an example that has a struct with a lifetime parameter implementing traits that have lifetime parameters. That's some ugly syntax!

jb19912• 3 years ago

Total tangential but I just did a quick search to confirm my suspicion: using the word "strawman" in an HN comment these days very highly increases chances of getting downvoted. It would be curious to analyze why this is, but my guess is that it has become a cliche and suggests a lack of original perspective.

CGamesPlay2• 3 years ago

Maybe. I was reusing the word from the article:

This is lifted straight from the standard library, so it is very much not a strawman example. And, at least to me, it’s definitely not a pretty one!

beezlewax• 3 years ago

Because many people think they've won an argument by throwing about terms like that or loosely related ones. It's like a bad language framework and is often inappropriately shoehorned into conversation by people who think it makes them look smart.

Reddit is atrocious for this and I suspect people don't want to see it get in the way of real discourse.

jokoon• 3 years ago

I prefer using a simplified subset of c++ than write rust. Meaning i just use the simple parts of c++.

This rust code reads like there is a lot to learn about rust. This is a big barrier.

scotty795• 3 years ago

There's a lot to learn about Rust. It's very different language from pretty much any mainstream language. Even C++. But it makes it very interesting to me. So far I've seen mostly either javesque-scriptish languages or type-algebraic-for-the-sake-of-type-algebra languages. There were some oddities like we-just-write-ast or Forth. But mostly languages seemed boring and only syntactically different.

Rust is high level value semantics running on bare memory kind of thing. It's meaningfully different and useful.

i_am_a_peasant• 3 years ago

I've written both C++ and Rust and I've basically settled for C++ without inheritance in all my personal projects. I think Rust made me a better C++ programmer. The problem with Rust is that even when you reach a point of understanding all the base things about the language, how traits work, generics, all the reference types, patterns like interior mutability etc, I've never gotten to a point where I can get an idea and quickly implement it in Rust. That just doesn't happen. With C++ on the other hand it is much easier to prototype, and I really need that being-able-to-quickly-prototype aspect in my workflow.

shmerl• 3 years ago

The point of the post basically demonstrates that all that syntax isn't just there to annoy you, but is driven by pragmatic needs to be explicit for performance purposes.

But the ending "much better" isn't really addressing the actual question of whether there is a way to improve syntax while keeping all things that need to be addressed instead of dropping them one by one like the post did.

ben0x5395• 3 years ago

I keep thinking Rust should allow you to skip the < > if there's only one generic argument. Like just say io::Result Vec u8. Much more lightweight and not ambiguous (but breaks macros people write). You can keep the angle brackets for multiple arguments like idk Vec HashMap<Option String, Result<i32, ()>>.

zozbot2346• 3 years ago

This would involve using whitespace as an operator. If you're going to do that (I'm not sure that it stays readable once you go beyond trivially small code snippets) I'd argue that the generic type should be postfix, as it is in the CrabML syntax.

And yes, these proposed syntaxes for Rust are not practical because Rust's support for macro definitions relies on the existing syntax. But if you're willing to reimplement any macros, it becomes viable.

ben0x5395• 3 years ago

That's wild actually, I've been aware that ML languages exist and had a rough idea what they look like but I never realized they do postfix generics. I'm going to have to let that bake in my brain.

WalterBright5• 3 years ago

D allows the () to be skipped for one template argument:

    X!(T)
    X!T

are the same. This was Andrei's idea, and it worked out nicely.

ben0x5395• 3 years ago

Yeah, I think that's very cool and reads nicely in a lot of cases. D is definitely always a language that comes to mind thinking about "has lots of important features" + "doesn't look crufty".

ssokolow13• 3 years ago

That was proposed and rejected for Rust recently:

https://github.com/rust-lang/rfcs/pull/3267

I was against because I felt that there should always be parens/brackets/braces (macros can use any of them) for better scannability when you're invoking an unclear amount of extra stuff behind the scenes.

(An appeal to the "make costs explicit" side of Rust's philosophy that also requires explicit .clone() rather than copy constructors.)

Here's the summary of why the consensus was "no":

https://github.com/rust-lang/rfcs/pull/3267#issuecomment-128...

dgfitz2• 3 years ago

I read until I saw “loosing” instead of “losing” to describe the loss of something.

scotty795• 3 years ago

Why the hell do loose and lose have the same "oo" sound? Lose sounds even longer than loose. It's asking for trouble.

jjgreen• 3 years ago

Why the hell do 'bough', 'borough', 'through', 'dough', 'rough', 'cough', 'brought' all pronounce the 'ough' differently? Welcome to English!

qbrass• 3 years ago

Writing 'o' and 'oo' to differentiate the two words was a workaround for not being able to write the letter 'z' in script, because it was easily mistaken for the letter 'ȝ'.

estebank8• 3 years ago

Are you a simple parser? Because you read until finding the first reason to stop and bailed out.

Marginally more advanced compilers will try to recover, get to the end with as much context as possible, and then complain, including maybe some extra info that came after that might be relevant to the error seen.

dgfitz2• 3 years ago

Ah shit, I’m a human not a fucking compiler. Apologies.

matklad3• 3 years ago

Sorry, dyslexic as heck even in my mother tongue! In writing I constantly mix even "thing" and "think", that's why there's 'fix typo' button :)

vore3• 3 years ago

The thing about the inner function is something I didn't know about and while I understand the motivation and need it definitely feels a little goofy. But if you're passing impl AsRef<Path> just to pass it as a &Path to an inner function, apart from slightly better ergonomics, there's not really any difference to just having the outer function accept &Path, no? That might the actual wart beyond just bikeshedding.

JoshTriplett3• 3 years ago

If you only accept `&Path`, then the caller will have to turn it into a `&Path` or you; that just moves the complexity from the one function to its many callers.

zozbot2346• 3 years ago

It would be more elegant to move the "inner" function to the top level, and expose a separate helper function that does conversion. The current Rust code seems to be constrained by backward compatibility, where the code was written with a generic interface to start with and this had to be preserved.

vore3• 3 years ago

I don’t think it’s so bad since conversion to &Path is pretty trivial. Conversely, impl AsRef<Path> can move the argument even though it only really needs a borrow, which is kind of funky (both PathBuf and &PathBuf are AsRef<Path>, after all).

zamalek• 3 years ago

I strongly disagree that Rust syntax is ugly, in absolute terms, even for the worst-case scenario presented in the article. Rust syntax is derived from a few very simple rules/concepts/themes. After observing how one set of operators/keywords combine, you should be able to make strong assumptions about how another set will combine.

Once the syntax sinks in, it's significantly easier to read than most other mainstream languages because there are significantly fewer rules/concepts/themes to comprehend.

As an extremely simple example, after learning what this does:

    let a = loop { break 1; };

you can bet the programmer can figure out what's going on here:

    let a = if true { 1 } else { 0 };

A language serves three purposes: it must be easy to write, it must be easy for a human to read, and it must be as unambiguous as possible (so that a computer can understand it). From a purely syntactical standpoint, Rust does great on all three. Most modern languages barely manage two.

* Form follows function. *

kazinator8• 3 years ago

A binary file is derived from a very simple rule:

(0|1)*

There: now you know everything from SVR4 UNIX executable format to H.264 video wrapped in MP4 container! Go forth and decode ...

Donckele2• 3 years ago

OK… So what does the first line of code do?

You might as well say what the second line of code does - will save me time replying again ;)

doctor_eval• 3 years ago

I have never written a line of rust in my life but I assume that a statement that terminates with a value can be used as a rvalue in an assignment or other expression.

So (I guess) both examples set the variable to 1.

at_compile_time• 3 years ago

Rust is an expression-based language, so a loop block is just an expression. Break exits the loop and returns the expression following the keyword, which is the integer 1 in this example, but it could also be nothing if the loop returns nothing (aka unit "()", aka void in some languages), or any other expression as well.

friendzis• 3 years ago

must be as unambiguous as possible (so that a computer can understand it)

A nitpick. Unambiguity (and other language features) is extremely important not that a computer can understand the language (it can), but rather that the understanding (or interpretation) of a program by programmer and computer are the same.

Bugs like off by one, use after free and similar issues quite often stem from this misunderstanding.

estebank8• 3 years ago

Source code is mainly a communication tool for other people, and less importantly, instructions for a computer. At the same time, compilers are an error reporting tool with a code generation side-gig.

jchw2• 3 years ago

It would be much simpler to not think about error handling at all, and let some top-level try { } catch (...) { /* intentionally empty */ } handler deal with it:

I dislike this, as even in C++, I like expected or StatusOr better than exceptions. I don't really think the Rust semantics for Result is that bad.

That said, if I were to fantasize about potential improvements, one thing I'd really like is an overhaul of error types in results. I wish there was some magical way that the error type could be inferred to be a union of all of the errors that can be returned. Most of the time, needing to explicitly do this manually doesn't add much value, and worse, it leads to much less precise error types as people reuse the same union type for functions that return disjoint errors. Unfortunately, there's no obvious way to make this work out, especially since it breaks Rust's rule about non-local inference, since the return type would be inferred by the function itself. Also, it would make life a lot worse for not breaking your API. But it would make the code a lot simpler and lower effort, that's for sure.

Perhaps another thing would be simply not needing to write out Ok(value), and just have an implicit conversion there, but while that could actually be done, it is also ugly for other reasons.

I don't see a problem at all with the ? syntax itself.

vore3• 3 years ago

One thing I wish was better was block-scoped ?.

I know there's https://doc.rust-lang.org/beta/unstable-book/language-featur... so you can do e.g.

   let foo: Result<T, Error> = try {
       x()?;
       y()?;
       Ok(z)
   };

but it hasn't been stabilized yet. The other workaround is to make an anonymous function and invoke it immediately, but sometimes you run into janky lifetime issues with that.

D4ckard• 3 years ago

I wish there was some magical way that the error type could be inferred to be a union of all of the errors that can be returned.

You could use `Result<(), Box<dyn std::error::Error>` to use dynamic dispatch at runtime and allow the function to return any type that implements `std::error::Error`.

Otherwise people often use the anyhow[1] or the thiserror[2] crate to easily work with errors. They allow concise error propagation and quickly creating custom error types.

[1] https://docs.rs/anyhow/latest/anyhow/ [2]: https://docs.rs/thiserror/latest/thiserror/

jchw2• 3 years ago

I usually use thiserror.

dyn Error would be fine by me performance-wise, but I do want to exhaustively know the exact possible kinds of errors a function can return statically at compile-time, and dyn Error thwarts that. It looks like anyhow Result is basically in the same boat, just with better ergonomics.

gimmeAnte• 3 years ago

This is the rust syntax we deserve: http://antelang.org/

matklad3• 3 years ago

+1, ante is a treasure trove of tasteful syntactic decisions.

ssokolow13• 3 years ago

To be honest, I've always been unnerved by "Why is that block ending without a } or END? Is the indentation significant? Is the number of arguments for each construct back-fed into the lexer?" languages like Ante, Ocaml, and Haskell.

valyagolev• 3 years ago

There's always a lot going on in every line of Rust and I respect that. But a lot of it is boilerplatey. E.g. this AsRef business - the argument is that it helps performance, but I hope that sometime in the future it would be much easier and cleaner to express things like "I want two arguments of any type I can transform to an owned string" without adding a bunch of explicit generic arguments, or even "I want a hashmap with keys and values of any type I can transform to an owned string", allowing people to use your api without adding/removing .to_owned() after strings every time they change something, or all this iter-map-to_owned business.

And no, I don't mean it as having java-like semantics. Semantically such functions should stay generic over the types. There's no reason not to sugar it over, though

oconnor663• 3 years ago

I want two arguments of any type I can transform to an owned string

Since Rust 1.26 you can write this:

    fn foo(x: impl Into<String>, y: impl Into<String>) {
        ...
    }

Which is almost exactly the same as this:

    fn foo<T: Into<String>, U: Into<String>(x: T, y: U) {
        ...
    }

zozbot2346• 3 years ago

But this has the same flaw as the original code in OP, where you need a separate inner function to avoid excess monomorphization. What's wrong with just taking a String (or a ref to Path) and expecting user to add .into() at the calling site?

deafpolygon3• 3 years ago

Let's put it this way... when you absolutely must syntax highlight code in order to be able to explain Rust syntax.. it's ugly.

Let's just go with a really contrived and stupid example... "pub fn". Would it really have killed them to spell it out? Why do we need 'fn'? Functions with a return type (i.e. `fn add(a: i32, b:i32) -> i32`) is just not easy to read. Yes, I'm aware that someone here will find this 'beautifully terse and concise', as well as easy to read. But without syntax highlighting, it's just a jumble of characters to me.

We read code more than we write, so clarity of code should be the goal of any 'modern' languages these days.

JoshTriplett3• 3 years ago

Brevity isn't always a bug even when optimizing for reading rather than writing. Spending extra characters spelling out `function` doesn't necessarily make code more readable.

I do, in general, think keywords should not be abbreviated. We have "return" rather than "ret", "continue" rather than "cont", and so on. This wasn't always the case; ancient (pre-1.0) versions of Rust had a lot more abbreviation in the language and library than current versions.

geoelectric• 3 years ago

I think there's a good reason for the function keyword to be abbreviated.

We know that when people read lines of text, they pay a lot of attention to the beginning and the end and comparatively less attention to the middle. One result is that lines with common prefixes tend to blur together. To get around this, you want the reader to encounter the unique portion of the line ASAP, which makes it desirable that any kind of necessary prefix be brief.

Upshot is you want the function signature to be what you see as you scan down the left side of the page, so it does make sense to keep the function keyword particularly concise.

Gigachad3• 3 years ago

There has to be a more objective way to rank uglyness. The example function you provided looks perfectly fine to me. I don't see how syntax highlighting makes it any better.

deafpolygon3• 3 years ago

I did mention it will look perfectly fine to someone here. [ and what better, to someone's nickname is Gigachad :) ] But if you had a sea of functions that looked just like that.. it'd be hard to pick things out without syntax highlighting.

kazinator8• 3 years ago

That's another thing. I don't want to see 32 and 64 crap in code that is supposed to be high level and portable.

i32 means I'm doing FFI with C libraries.

If you check the Rust documentation, you see it has no integer types that are not a fixed size.

"All the world is x86/ARM (formerly DEC VAX / Sun SparcStation )"

C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.

lmm7• 3 years ago

C started on 18 bit machines. A program that correctly used "int argc" for the main argument count runs on an 18 bit machine or a 16 bit machine without modification.

I'm guessing you're too young to remember the 32 -> 64 bit transition, because this is backwards in practice. Non-fixed integer sizes are a nightmare for portability and the reason why some C code still hasn't been ported even today, whereas programs in e.g. Java or OCaml ran without modification on the new machines.

A modern language should make it easy and first-class to use arbitrary-precision integers and decimals though.

the_mitsuhiko• 3 years ago

Not once did I want a magically differently sized integer. But if you do, Rust has these.

adrianN• 3 years ago

I on the other hand like that _int_ doesn't mean "some integer of implementation defined width". I want to know for sure how big my numbers can be and how much memory an array of such numbers consumes.

timlatim• 3 years ago

Personally, I struggle to see what's good about unspecified-but-fixed-width integer types as in C/C++. A lot of real-world code I see uses uint32_t (sometimes typedef'd to u32) and the like to get predictable data layout and to avoid cute gotchas like long being 64-bit on x86_64 Linux but 32-bit on Windows.

I also like how Rust makes both signed and unsigned types equally easy to type, because I feel that a lot of people use signed integers where they should be using unsigned simply because it's easier to type "int" compared to "unsigned (int)". And if you absolutely need a machine word size dependent type in Rust, you do have usize, which is the equivalent of size_t.

imtringued• 3 years ago

I am seriously confused. Using fixed size integers is about correctness. Randomly changing the size of your integers will cause unexpected integer overflows.

I16 and I64 is more concise than short and long and it is immediately obvious what the number range is for a beginner. The only complaint regarding portability is the unstated assumption that every computer can only store two values per bit. A hypothetical QLC based computer might store a I64 number in 32bits.

interroboink2• 3 years ago

Funnily, nearby on the frontpage is The Python Paradox[1], an essay which contains:

  > At the mention of ugly source code, people will of course think of
  > Perl. But the superficial ugliness of Perl is not the sort I mean. Real
  > ugliness is not harsh-looking syntax, but having to build programs out
  > of the wrong concepts. Perl may look like a cartoon character swearing,
  > but there are cases where it surpasses Python conceptually.

I do think there's something to be said for the notion of "conceptually ugly" rather than "syntactically ugly", though the latter is what people tend to focus on. Perhaps we need a better word than "ugly," with its superficial connotations.

[1] https://news.ycombinator.com/item?id=34541933

nequo• 3 years ago

A “conceptually beautiful” language would consist of orthogonal concepts, right? What would be good examples of such languages?

Interestingly, Python’s aspiration to have only one (obvious) way to do things could be understood as an aspiration to achieve conceptual beauty.

timeon• 3 years ago

stupid example... "pub fn".

I just don't get why this even gives someone pause.

zanellato192• 3 years ago

Wait, do you want functions _without_ a return type?

I don't understand this complaint on a statically typed language.

conradludgate3• 3 years ago

In theory the return type can be inferred by the body of the function given the fixed argument types.

However rust has made the stance that the full signature is required for the reason of local static analysis. If you have a function A that calls another function B, you shouldn't need to analyse B in order to analyse A (both as a human and as a compiler)

gigel82• 3 years ago

The syntax is honestly what's keeping me away from Rust; it's ugly AF.

I jump into an unknown C++, or TypeScript / JavaScript or C# codebase and it's just readable and easy to understand. I read a bit of complex Rust and it's making me queasy.

lukebitts3• 3 years ago

I find caring about a language being “ugly” such a weird concept. Like, imagine caring that a hammer is pretty or not… All I care about is how well it can hammer my nails and that’s literally it.

Torkel• 3 years ago

I care a lot about how nice my tools are. Beauty is for sure important in all human endeavours.

lukebitts3• 3 years ago

I care about how nice my tools are as well, but notice "nice" implies usefulness. Beauty? beauty is irrelevant, and it is irrelevant in many human endeavors where it is not treated as such.

c54• 3 years ago

Your interface with the hammer is your hands, so you might care if the grip is rough or slippery, apart from how well it hits nails.

Your interface with code is your eyes, so it can matter a lot how it appears. We read code more than we write, so writing for legibility is important. People talk about line noise. And we use syntax highlighters and monospaced fonts. All of this is for appearances.

lukebitts3• 3 years ago

My interface with code is definitely not my eyes. My interface with code is the mental structures I keep in my mind while coding. Rust is perfectly legible, even better than legible, because all the structures in my mind can be simpler since the language guarantees so much on its own. Something as superficial as wether the language uses :: or whatever doesn’t even register while I’m programming.

Also, that was a nonsense metaphor for you to use. The grip being slippery is so far removed from “beauty” that not even trying to change the subject to be about “interfacing” can redeem it.

C++ is a slippery hammer, not because it’s ugly, but because it’s easy to hit yourself in the foot using it.

WalterBright5• 3 years ago

Let's have some fun with the article's example:

    pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
      fn inner(path: &Path) -> io::Result<Vec<u8>> {
        let mut file = File::open(path)?;
        let mut bytes = Vec::new();
        file.read_to_end(&mut bytes)?;
        Ok(bytes)
      }
      inner(path.as_ref())
    }

In D (I'm not a Rust expert, so apologies for inevitable mistakse):

    public io.Result!(ubyte[]) read(P : Path)(ref P path) {
      io.Result!(ubyte[]) inner(ref Path path) {
        auto file = File.open(path);
        auto bytes = file.read_to_end();
        return Ok(bytes);
      }
      inner(path);
    }

boxed• 3 years ago

Putting the return type to the left of the function name is pretty bad. So C/C++/D loses quite a bit on that at least...

LegionMammal978• 3 years ago

Some nitpicks, since you're almost asking for them:

'read' taking 'ref P path' isn't entirely accurate. In Rust, 'path' is moved into the 'read' function, which destroys it after calling 'inner'. (If the caller doesn't want it to be destroyed, it provides a reference, i.e., a safe non-null immutable pointer; when 'read' destroys the reference, nothing happens.) As I understand it, 'ref P path' in D still gives the caller the ability to access 'path' after calling 'read' and the responsibility for destroying it.

Also, the '?'s are important for error handling: the 'File::open()?' line basically expands to

  let mut file;
  match File::open(path) {
      Ok(value) => { file = value; }
      Err(error) => { return Err(error); }
  }

and similar for the 'read_to_end()?', except the result is discarded. And one of the reasons (apart from flexibility) that 'read_to_end()' takes an external vector as input is so that the caller can retain the result of a partial read; otherwise, the function would have to return a vector on error as well as on success.

WalterBright5• 3 years ago

I understand that Rust has somewhat different semantics, but for purposes of illustration I focused on the syntax.

For example, D could would likely throw an exception, rather than use pattern matching, for error handling.

zumu• 3 years ago

Rattlesnake is actually pretty good. I also like CrabML but I wouldn't expect that to be popular though.

In general, I don't love Rust's choice of sigils (::, <>, etc), but the language reads well enough. That inner/outer function thing is legit the compiler model leaking into user code though.

haskman6• 3 years ago

They didn't explore a Haskell (or PureScript) inspired syntax, but I think it could massively improve things without compromising on semantics. The separate function signature itself is a great improvement.

"Haskell flavored Rust" anyone?

    read
      :: forall p
      .  AsRef Path p
      => p
      -> Result (Vec u8)
    read path = inner (as_ref path)
      where
      inner :: &Path -> Result (Vec u8)
      inner path = do
        mut file <- File.open path
        let mut bytes = Vec.new
        read_to_end file (&mut bytes)
        pure bytes

Yoric3• 3 years ago

I was actually thinking of working on something like this as a side-project in case I was laid off...

haskman6• 3 years ago

I've been thinking about something like this for a while too. Happy to collaborate!

tluyben2• 3 years ago

I guess they didn’t explore a Haskell (or a Lisp, Prolog (which always surprises me by looking so clean that you don’t think anything can be going on), Python, Pascal etc) style because it scares c/c++ programmers generally. And then they would have to fight harder for adoption than they had to now.

Personally I think many styles, like the Haskell-y you show here, would be far more pleasing on the eye; luckily we live in a time where it is not too hard to create either a different compiler frontend, or, easier, a translator (transpiler, but I don’t like the word as it only translates, hence it takes too much credit being called transpiler).

haskman6• 3 years ago

Yup, this could and should be a separate preprocessor step. Changing the syntax of the Rust language itself so drastically would be nearly impossible at this stage.

afdbcreid• 3 years ago

While this is true, we are still in a time when seeking adoption for this newly made syntax is much harder.

culebron212• 3 years ago

It looks better, but hard to comprehend without looking into the original code. E.g. this line:

    inner path = do

Generally speaking, improved syntax would have been great, but similar projects that existed 10-15 years ago failed to be adopted widely (CoffeeScript, HAML).

haskman6• 3 years ago

Why is that hard to comprehend? `do` starts a new block with sequencing semantics (so we don't need the `?` operators) in Haskell.

CoffeeScript can actually be considered very successful, since it influenced the design of a lot of other language features we take for granted. Same can be said for HAML.

brmgb2• 3 years ago

Of course, they did. The initial compiler was written in Ocaml.

Early Rust looked much more like a ML language. They intentionally moved to a C-like syntax because it is more familiar to their target audience.

haskman6• 3 years ago

I didn't mean the designers of Rust. I meant the author of the article did not consider a Haskell like syntax.

I completely understand the reasons for Rust devs targeting a C like syntax. Rust had already blown its novelty budget on the borrow checker semantics.

oslac• 3 years ago

The lifetime stuff in library code gets very ugly and unreadable very fast.

verdagon• 3 years ago

I think the reason Rust's syntax is so controversial and divisive is that its syntax works well for some areas and poorly for others.

TFA highlights it well:

It is needed because Rust loves exposing physical layout of bytes in memory as an interface, specifically for cases where that brings performance.

Rust (and its syntax) is designed for precision and performance and explicitness. That's great for the parts of your code that are extremely performance sensitive.

However, for most of our code, we need flexibility and high-level readability a bit more... a bit of a mismatch with some of Rust's decisions.

I like C#'s approach here. By default it decouples away all of these unnecessary low-level decisions, and lets you focus on what the code is actually trying to do. Then, if you want to do performance-sensitive work, you can use things like `struct`. I wish it went a bit further, but it's pretty nice.

Yoric3• 3 years ago

I like C#'s approach here. By default it decouples away all of these unnecessary low-level decisions, and lets you focus on what the code is actually trying to do. Then, if you want to do performance-sensitive work, you can use things like `struct`. I wish it went a bit further, but it's pretty nice.

But if I read correctly what you wrote, that's not just syntactic, right?

low_tech_punk3• 3 years ago

Is this a sarcasm piece from the author? The way the article ends (by throwing away more and more features from Rust) makes me wonder how sincere the beginning was.

mlindner2• 3 years ago

I think the intent is to show first by counterexample that, no, the syntax is quite readable for what it's trying to represent. After showing that the syntax isn't the problem they then show that the language semantics are indeed what make it complicated, but you can only get away from that by throwing away the best features of Rust.

Basically they're criticizing, in a roundabout way, people who criticize Rust for it's syntax by showing that such people don't actually understand Rust.

low_tech_punk3• 3 years ago

Thanks for this explanation. I finally got the point :)

GolDDranks4• 3 years ago

It has a sarcastic tone, but the point is to show by demonstration that the ugliness is not purely in the syntax, but because Rust actually exposes a lot of knobs to the programmer.

low_tech_punk3• 3 years ago

My personal nightmare is Fn, FnMut, and FnOnce. I always got them in the opposite order as I intended.

estebank8• 3 years ago

If when trying to use them the compiler fails to provide adequate feedback to get you on track, please file diagnostics tickets! We take them seriously.

ssokolow13• 3 years ago

I think they're saying that it's counter-intuitive that the specialization relationship between Fn, FnMut, and FnOnce is the reverse of foo, &mut foo, and &foo.

I know it took me a long time for that to stick.

conradludgate3• 3 years ago

Fn: a function that can be called many times without side effects. Can be shared. Almost exactly like regular functions besides the capturing.

FnMut: a function that can be called many times but can have side effects, because of this it must be exclusively held (&mut F)

FnOnce: a function that can be called only once, making use of by-ownership function calls

So I remember it like Fn: just a function FnMut: a function that needs &mut access FnOnce: only used once, moving ownership

puffoflogic2• 3 years ago

I'd say that because of everything-is-an-expression, and items (e.g. functions, type definitions) allowed in block scope, rustc will accept exceptionally opaque syntax compared to other languages.

But that doesn't mean that you should be writing exceptionally opaque syntax. For example, in the given example, I would demand that <T: AsRef<Path>> be written with a where clause instead. rustc will accept either, but humans should demand `where` at least whenever the traits contain `<>`.

lmm7• 3 years ago

It's funny how even the final example does look ugly; all those unnecessary ;s , ::s and {}s. This article has convinced me of the opposite of what it was probably trying to claim: Rust syntax is not just trying to express difficult concepts, it's genuinely bad.

estebank8• 3 years ago

I'm absolutely biased, as one of the rustc parser maintainers, but removing all redundancies of a languages syntax is actually terrible for usability. The fewer "landmarks" the parser has to work with, the harder job tooling has to provide feedback when something was written incorrectly and increases the likelihood of two unrelated concepts being a typo away, which won't be caught by the compiler. Increased verbosity doesn't have to mean reduced readability, as long as the syntax is regular and allows you to selectively skim parts of the code you don't currently care about.

lmm7• 3 years ago

Syntactic noise absolutely reduces readability. Redundancy may have value sometimes, but ignoring the information that's already there (newlines and indentation) in favour of a separate, parallel track isn't actually giving you more chances to catch an error, because indentation that doesn't match the blocks or newlines in the middle of an expression are generally a warning at best.

simon_o2• 3 years ago

It's not about removing redundancies or landmarks, it's about Rust having made some not-so-good choices.

It's slowly becoming apparent to more people (e. g. compare the screeching a few years ago about Rust's wrong choice of <>/::<> generics to today), which I guess is why we see more of these huffy articles from Rust defenders.

alkonaut• 3 years ago

I think it’s reasonable that std library code goes to one extreme of ugly-but-performant while in my own code I can choose something slightly more elegant. Such as avoiding a nested function.

So while I agree with some of the points of Rust having a tendency for hiding the what in all the how (and token salad), I think looking at the stdlib isn’t always a good example of idiomatic Rust.

kramerger• 3 years ago

This is a very insightful observation! The C++ template library is at times unreadable too.

But I do belive that rust is somewhat ugly and more complicated than C++ - for no reason other than a bad syntax design.

mlindner2• 3 years ago

I love this post. It's a great example of how to mock an opinion that too many have followed by utterly destroy it.

gardaani• 3 years ago

Rust made a strange decision abbreviating keywords which are significant (pub, fn) and making things verbose where it isn't needed (separate declaration of P). Here's how my dream syntax for Rust would look like:

    public func read(path: AsRef<Path>) -> io.Result<Vector<u8>> {
      func inner(path: &Path) -> io.Result<Vector<u8>> {
        var file = File.open(path)?;
        var bytes = Vector.new();
        file.readToEnd(&mut bytes)?;
        return Ok(bytes);
      }
      return inner(path.asRef());
    }

I have replaced pub with public, replaced fn with func, removed separate declaration for P, replaced :: with ., replaced Vec with Vector, replaced let mut with var, replaced snake_case with camelCase, added return keywords. Note that all these are syntax changes. Semantics hasn't been changed at all. One more thing would be to remove the semicolons..

Compare that to the original. Which one is more readable?

nneonneo2• 3 years ago

`impl` exists now, so you can write

    pub fn read(path: impl AsRef<Path>) -> io::Result<Vec<u8>> {

in Rust without needing to declare P separately.

GolDDranks4• 3 years ago

I like the real Rust syntax more, save for double colons. (And I might prefer other brackets to <> with generics) But how is that syntax of yours separating types and generics with traits? Currently `AsRef<Path>` looks like a type although it's not supposed to be one.

scotty795• 3 years ago

Do they really need to be separated? Does it matter all that much when you are creating a function whether parameter is a specific type or just sny type that implements specific trait?

throwbadubadu• 3 years ago

You complain about abbreviation of omnipresent keywords, but then allow function only two more letters? :D I think proofs well, syntax is overrated and it is all opinionated taste..

Which one is more readable?

Not seeing any difference.

rob74• 3 years ago

Yeah, that's my main gripe with Rust as well: the lack of human-readable words ("pub", "fn" and "mut" are abbreviations, not words, and "return" was even abbreviated to an empty string) and the high density of esoteric special characters.

ssokolow13• 3 years ago

"return" wasn't "abbreviated to an empty string", it's that Rust is expression-oriented, the value of a block is the value of its last expression, adding ; turns expressions into statements, and a function with no terminal expression returns (), which serves the same role as void.

    fn foo(x: u8) -> u8 {
        let y = {
            let z = something();
            x + z
        };
    
        y
    }

TL;DR: It's not a property of the function, it's a property of the curly braces.

Zababa• 3 years ago

I think the original is more readable. I especially don't like "return thing;" when it could be "thing" instead, as I prefer expressions.

Measter4• 3 years ago

One thing you've missed here is that `let mut` is two different things: `let` is the keyword for creating a new binding, while `mut` is part of the pattern that `let` binds to. For example, you can pattern match a tuple and make one value `mut` and the other not:

    let (a, mut b) = //some tuple

You can't just replace `let mut` with `var` because it changes the semantics of the code.

RazrFalcon2• 3 years ago

You're basically describing Swift:

    public func read(path: URL) throws -> Array<UInt8> {
        let file = try FileHandle(forReadingFrom: path)
        let bytes = try file.readToEnd() ?? Data()
        return Array(bytes)
    }

Yes, the example above is not generic and not even idiomatic Swift, but it's a good glimpse into how Rust could look like.

Hopefully someday Swift would become more safe, less tied to ObjC legacy and actually cross-platform. It's a shame that such a nice language is basically Apple-only.

matklad3• 3 years ago

You are looking for Val I think: https://www.val-lang.dev/

baysmith• 3 years ago

I think using . for both field/method access and name pathing would hurt readability and make name lookup more difficult. Perhaps replace :: with a backtick instead?

  use std;
  use std`fs`File;
  pub fn read<P: AsRef<Path>>(path: P) -> io`Result<Vec<u8>> {
    fn inner(path: &Path) -> io`Result<Vec<u8>> {
      let mut file = File`open(path)?;
      let mut bytes = Vec`new();
      file.read_to_end(&mut bytes)?;
      Ok(bytes)
    }
    inner(path.as_ref())
  }

conradludgate3• 3 years ago

You already don't need the generic syntax. You can use `impl AsRef<Path>` if you don't need to name the generic anywhere else.

blub• 3 years ago

The problem is not the brackets, and the colons and so on, but rather the cultural habit of wanting to cram as many concepts as possible into as few lines as possible.

A Rust function has to be generic and fast, it should absolutely use references and also Result types, some functional idiom and generally encode as much as possible in the type system. When other languages would settle for another if or an exception, Rust always has one more weird trick up its sleeve to use instead.

This is the curse of the bigbrain programmer wanting to use bigbrain concepts everywhere. Crate and library developers have internalized these lessons and it has become a self-fulfilling prophecy.

hknmtt• 3 years ago

rust is the sloth from goonies.

awb• 3 years ago

Building a language that functions well is different from designing a language that reads well.

Just like building an app that functions well is different from designing an app that looks great.

We don’t expect every backend developer to be the best front end designer and at some point we shouldn’t expect every language developer to be the best language designer.

It might be worth treating these two tasks as separate disciplines that can be studied and practiced independently.

Otherwise, we keep getting languages that feel akin to 1990’s websites. They function great, but look as if the aesthetic is an afterthought.

brundolf2• 3 years ago

I think most of what people call Rust's "ugliness" is actually just Rust's explicitness. You have to chain a lot of method calls for things that might happen implicitly in other languages; you have to annotate lifetimes and constrain generic type params; sometimes you have to manually parameterize the generics you're using; etc. But I think most of that is unavoidable without shifting some of Rust's core values.

The only piece of surface-level syntax that I'm really truly bothered by is the closure syntax:

  fn_with_a_callback_1(|param| param + 2);

  fn_with_a_callback_2(|param| {
    println!("{}", param);
  });

- The fact that the | | is the same character on each side

- The lack of directionality from the args -> to the body

- The lack of any kind of overlap with the normal function syntax fn foo()

Especially compared with something like JavaScript which has a really lovely lambda syntax, this one's hard to look at. I'm sure there were good reasons around ambiguity with other syntaxes or something, but... eesh.

lifthrasiir2• 3 years ago

To my knowledge, this closure syntax was a direct Ruby influence mainly because this syntax was also supposed to work like Ruby blocks: `array.each |e| { ... }`. Originally owned and shared closures had a different syntax (`fn~() { ... }` or `fn@() { ... }`)---this was back when Rust had a built-in shared reference, roughly equivalent to `std::sync::Arc` in the modern Rust---and it was pointed out that they should be harmonized at some point [1]. It was that time when people realized that then-loop-only syntax can be generalized into any closures, and this semi-decision got stuck even after the "internal" iterator that accepts a closure has long gone.

[1] https://github.com/rust-lang/rust/issues/1864

fsckboy• 3 years ago

I think most of what people call Rust's "ugliness" is actually just Rust's explicitness.

I think most of what people call C's ugliness is actually just C's power. Some of it is C's age: we can't blame C for being born in the very early 1970s (when sensible ISAs were just born), but when you update C, don't try to make it be something that it's not. You see the beauty of UTF-8? People who could not have invented UTF-8 can at least see the beauty of UTF-8. Unfortunately, people who could not have invented C, are updating C.

When you try to update C, not only don't wreck it, don't try to replace it with something emo, weak, and overwrought, which is what Rust is.

C is powerful, natural, and concise. It doesn't wipe your ass for you. Wiping your ass neatly is not something you want to entrust to a bulletproof syntax, not when you can always just wash your hands. Rust? Rust has the color of not washing your hands because Rust imagines that it made it unnecessary.

Already__Taken2• 3 years ago

I'm just surprised anonymous fn () { } wasn't the obvious choice for closure.

majewsky• 3 years ago

This is pretty much the closure syntax used by Go, and it's one of its biggest issues (IMHO). Even if you had map/filter/etc. methods on slices, it would still look like:

  squares := numbers.
      filter(func(x int) bool { return x >= 0 }).
      map(func(x int) int { return x * x })

With what I understand to be your suggested Rust syntax, this would still me:

  let squares: Vec<_> = numbers.iter()
      .filter(fn(x: i64) -> bool { x >= 0 })
      .map(fn(x: i64) -> i64 { x * x })
      .collect();

which is a lot of noise compared to

  let squares: Vec<_> = numbers.iter().filter(x => x >= 0).map(x => x * x).collect();

brundolf2• 3 years ago

Yeah, I tend to agree. I do think it's important that the { } be optional, for single-expression lambdas, but something along these lines would've been much more readable imo if it were possible to fit into the grammar

edflsafoiewq2• 3 years ago

But I think most of that is unavoidable without shifting some of Rust's core values.

Well yes. Turns out beauty is not just skin deep. Semantics actually matter. You can't make a beautiful language by slapping some magical surface syntax on top of any language you like.

scotty795• 3 years ago

Personally I'm fine with semantics but I don't like how lifetime arguments are mixed with template arguments and how types that contain and behave like borrows have no visual indication of that in their names.

Measter4• 3 years ago

[...] but I don't like how lifetime arguments are mixed with template arguments [...]

It does make sense if you think of lifetimes as being part of a type system. Almost all lifetimes are generic (aside from 'static), so it kind of makes sense to put them in the section for declaring generic parameters.

It also works for how you constrain lifetimes: `'foo: 'bar` means that `'foo` outlives `'bar`, but could also be read as `'foo` inherits `'bar` because, like in type inheritance, a `'foo` can be used anywhere that wants a `'bar`.

nirui• 3 years ago

The article only provided one small example, and the code is not really that ugly. There are many third-party projects/libs that exposes way more ugly APIs, specially those which heavily utilize generics and `where`s. These things, while small and can be improved individually, wears programmers down quickly.

The syntax design of Rust is adding to the situations as well. For example, Rust is probably the only language that makes me cautious about the usage of semicolon, as you might have loads of unsound problems if you misused one.

My experience with Rust has been generally great, but I think these small details really deserves some thoughts from the Rust team.

BTW: I also wouldn't really trust those people who have to navigate through all the quirks of something, and then calling their experience "Great". There are people who memorized the entire `:help` book of `vim`, just so they can use the editor at hyperspeed instead of lightspeed. Those people are monsters, they can eat RAM chips and then spit out the bits cache line by cache line. You give them a grab of sand, they'll make a computer out of it and play DOOM on the computer. So of course those people well have great experience on almost everything (Or they just been polite, like me)

thom• 3 years ago

One of the suggestions I liked from Uncle Bob’s Clean Code was that the contents of each method should be at a single level of abstraction. In languages that require constant bookkeeping this is either impossible or requires sacrificing performance or correctness. The level of satisfaction reported amongst Rust programmers implies this isn’t an enormous issue for them, but I don’t know if we as an industry have reliable measures of productivity and correctness. Either way, nice that Rust is able to devolve into a less optimal but simpler language in the ways shown in the article. I often feel some guilt when giving up on highly templated C++ and doing things the OO way, but it’s simpler to reason about and still plenty fast.

sweetjuly• 3 years ago

I would actually love an ML frontend for Rust. I've always felt it was just such a nice and legible way to write code, hope CrabML someday becomes a real thing

kgbcia• 3 years ago

Is it possible to generate a language that just uses reserve words. I like how Python uses "and" and "or" instead of && and ||

heavenlyblue• 3 years ago

I am wondering if author is the one who would use all of those nasty-but-beautiful utf special maths/greek characters which were super-popular a couple of years ago.

I don't find Rust's syntax ugly. But then I don't find Modern Art ugly as opposed to what many people think so well...

throwaway234623• 3 years ago

IMO, Rust isn't going to scale well

* horrible syntax

* crates.io is a graveyard of typo-squatting and lacks quality control, and no vendors / namespaces

* slow compilation

* standard library doesn't have HTTP, requires third-party libraries that are still immature / suck.

* widespread & prevalent abuse of .unwrap()

* error handling sucks because rust lacks set-theoretic types

* rust's async doesn't mesh with structured concurrency

* rust's async requires third-party libraries like tokio

highlights of rust

* pattern matching + ADTs

* move by default

* affine types

* concurrency & parallelism are easy

* serde crate

* kube crate

* rayon crate

zanellato192• 3 years ago

Rust has already scaled well.

ssokolow13• 3 years ago

* standard library doesn't have HTTP, requires third-party libraries that are still immature / suck.
* widespread & prevalent abuse of .unwrap()

[citation needed]

* rust's async requires third-party libraries like tokio

As opposed to baking Tokio in and having people lament that they can't replace the executor for stuff like embedded use-cases?

I remember hearing that there's interest in using async/await inside the Linux kernel with a custom executor.

rfoo• 3 years ago

If we make PathRef an alias of AsRef<Path>, the following code looks much prettier to me:

pub fn read(path: PathRef) -> io::Result<Vec<u8>> { fn inner(path: &Path) -> io::Result<Vec<u8>> { let mut file = File::open(path)?; let mut bytes = Vec::new(); file.read_to_end(&mut bytes)?; Ok(bytes) } inner(path.as_ref()) }

I don't see noise in the remaining code, like the author said, they all have meaningful semantic (besides the repeated return type).

yakubin• 3 years ago

IMO The author proved here that Rust could have a much better syntax, when they showed the CrabML example.

jeremychone3• 3 years ago

Code aesthetic appreciation is a temporal matter. Something that looks ugly initially might feel natural and sound later. This happened a lot to me while learning Rust.

Rust has to be learned, true, but once the initial learning phase is done, those syntaxes start making sense and become part of the value rather than the cost.

I would recommend putting personal aesthetic preferences aside while learning and reassessing them later.

Also, I hope the article's point was not lost. It took me too long to get it, but I am glad I did before I wrote my first comment on Reddit a few days ago.

jeremychone3• 3 years ago

It's interesting. The same post was on the Rust Reddit a few days ago, and almost everybody got the point of the article, which is the opposite of what we could infer from the title alone. Many have a good laugh as well.

But somehow, on HN, the article seems to have been taken literally with long threads about "::" v.s. "." and how < > are bad for generics.

Physics over optics, not everything is about cosmetics.

Rust's Ugly Syntax

Related Stories