Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's Ugly Syntax (2023)

matklad.github.io

Post reply on HN
Print view View original

91–100 of 171 posts

Re: Rust's Ugly Syntax (2023)

#91

Post by jiwangcdi »

K0nserv wrote: post #59
jiwangcdi wrote: post #48

Earlier quoted context omitted.

Then if Path is not about abstraction, why not use a raw byte slice like &[u8]

That's orthogonal. If the type was `&[u8]` instead of `Path` the type signature would be: pub fn read >(path: P) -> Result > The reasons for it to be generic and us `AsRef` remain. The reason for Path over &[u8] is, AFAIK, because not all byte slices are valid paths on all OSs, but also because a dedicated type lets the standard library add methods such as `Path::join`

So abstraction is still a point, but Rust cares about memory layout as well.

Re: Rust's Ugly Syntax (2023)

#92

Post by dmurray »

namjh wrote: post #55
Hamuko wrote: post #46

Earlier quoted context omitted.

I do remember the compiler constantly suggesting lifetimes to me as a newcomer to the language, so it didn't really feel that opt-in. Quite a lot of the suggestions also started to look like someone poured alphabet soup all over the code.

That's because the code triggering compilation error is using reference. If you use Rc or Arc (which pays runtime cost) there should be no lifetime at all. Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust. And the clums…

> And the clumsy Arc>> makes users feel bad about using runtime cost paid types

Yeah, this would look worse than any of the "complicated syntax" examples in the blog post.

A language should be designed so that the typical case is the easiest to read and write. Syntax for the most common abstractions. Rust forces you to be explicit if you want to do an Arc>>, but lets you inherit lifetimes almost seamlessly. That means it's not idiomatic to do the first, and it is to do the second.

Languages with a lot of historical baggage don't follow this pattern: if you want to write idiomatic modern C++ it's going to be uglier and more verbose than you see in K&R. But in Rust's case it's clear what the designers encourage you to do.

Re: Rust's Ugly Syntax (2023)

#93

Post by kitkat_new »

jeroenvlek wrote: post #89
mrweasel wrote: post #63

Earlier quoted context omitted.

The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language. It's made worse by the fact that you can still use '...' as s character literal. Not only is is incredibly ugly it's also rather confusing, but it fits well into how I view Rust, complicated for the sake of making the developers look smart. It wouldn't fit the syntax of the language obviousl…

A lifetime keyword would actually go a long way in improving ergonomics. You could even make it synonymous with '. Then people can choose. Maybe one will get much more traction and the other can be deprecated.

why?

It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line

Re: Rust's Ugly Syntax (2023)

#94

Post by thesuperbigfrog »

mrweasel wrote: post #63
WhyNotHugo wrote: post #54

Earlier quoted context omitted.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language. It's made worse by the fact that you can still use '...' as s character literal. Not only is is incredibly ugly it's also rather confusing, but it fits well into how I view Rust, complicated for the sake of making the developers look smart. It wouldn't fit the syntax of the language obviousl…

>> The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language.

' has a long history of use for various purposes in programming language syntax not derived from C.

In Ada, attributes are a single quote followed by the attribute name.

If I have an enum called Fruit then Fruit'First would give the first value in the Fruit enum definition.

http://www.ada-auth.org/standards/22rm/html/RM-4-1-4.html

Attributes provide meta information about types and are very useful when working with custom integer types and ranges:

https://learn.adacore.com/courses/advanced-ada/parts/data_ty...

Using ' for Rust lifetimes or Ada attributes is just a sigil https://en.m.wikipedia.org/wiki/Sigil_(computer_programming)

It is not too different from:

    & for addresses / references in C, C++, and Rust, 

    * for dereferencing in C, C++, and Rust  

    $ for value substitution in shells and scripting languages

    : to mark keywords in Clojure and some Lisps

Re: Rust's Ugly Syntax (2023)

#95

Post by amenhotep »

mjburgess wrote: post #22
tcfhgj wrote: post #14

Earlier quoted context omitted.

To me this example is not more clear than normal Rust

If you've programmed a lot in Rust, then that's a win -- since its "not more clear", and yet, you've no experience in this syntax.

He said "not more clear" and yet you're responding as if he'd said "not less clear" or "exactly as clear"? This seems strange?

Re: Rust's Ugly Syntax (2023)

#96

Post by littlestymaar »

LoganDark wrote: post #18
sedatk wrote: post #2

I think the article makes a good point, but the actual example isn’t Rust’s worst, not even close. It gets really hard to follow code when multiple generic types are combined with lifetime markers. Then it truly becomes a mess.

I always, always forget what `'a: 'b` means, because I remember it always being the opposite of what I think it is, but memorizing that obviously doesn't work because then it will just flip again the next time. It's so annoying.

I had the same problem until I realized this: for generics and traits T: A means T implements A and it's actually the same with lifetimes: 'a: 'b means lifetime 'a implements lifetime 'b, which naturally translates to objects with lifetime 'a lives at least as long as 'b.

Re: Rust's Ugly Syntax (2023)

#97

Post by _answ »

mjburgess wrote: post #9

Kinda disingenuous, you don't reskin one language in another to make an argument about syntax -- you develop a clear syntax for a given semantics. That's what rust did not do -- it copied c++/java-ish, and that style did not support the weight. When type signatures are so complex it makes vastly more sense to separate them out, Consider, read :: AsRef(Path) -> IO.Result(Vec(U8)) pub fn read(path): inner :: &Path -> I…

I have a feeling that most of the clarity you find in your example comes from better use of whitespace. Consider:

    pub fn read
(path: P) -> io::Result>
    where
        P: AsRef,
    {
        fn inner(path: &Path) -> io::Result> {
            let mut bytes = Vec::new();
    
            let mut file = File::open(path)?;
            file.read_to_end(&mut bytes)?;
    
            Ok(bytes)
        }
    
        inner(path.as_ref())
    }
Plus, your example does not have the same semantics as the Rust code. You omitted generics entirely, so it would be ambiguous if you want monomorphization or dynamic dispatch. Your `bytes` and `file` variables aren't declared mutable. The `try` operator is suddenly a statement, which precludes things like `foo()?.bar()?.baz()?` (somewhat normal with `Option`/`Error`). And you weirdly turned a perfectly clear `&mut` into a cryptic `&!`.

Please don't assume that the syntax of Rust has been given no thought.

Re: Rust's Ugly Syntax (2023)

#98

Post by xelxebar »

mrweasel wrote: post #63
WhyNotHugo wrote: post #54

Earlier quoted context omitted.

Here's a nice example of a Trait that has async functions: fn list_items ( &'life0 self, collection_href: &'life1 str, ) -> Pin , Error>> + Send + 'async_trait>> where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, Rendered docs: https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag... Source: https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/v2.0.0-beta...

The use of ' as a symbol that has any meaning on it's own has got to be one of the most stupid choices I've seen in a language. It's made worse by the fact that you can still use '...' as s character literal. Not only is is incredibly ugly it's also rather confusing, but it fits well into how I view Rust, complicated for the sake of making the developers look smart. It wouldn't fit the syntax of the language obviousl…

Wait. Are you a Cobol programamer? Your argument has nothing to do with ' per se; it's completely generic for every "symbol" in a language.

    https://www.mainframestechhelp.com/tutorials/cobol/arithmetic-statements.htm
"Confusing" is mostly a question of familiarity; "ugly" one of taste. When you're designing a language's syntax, there is a tension between making the language feel recognizable to beginners/non-users and communicating important information saliently to experts. The former errs on the side of least-common-denominator symbols and explicit constructions, while the latter errs on the side of expression density and implicit understanding.

Language features that appeal to beginners and outsiders naturally aid in language adoption, even if they actively work against expert practitioners. So, funnily enough, we should a priori expect the zeitgeist opinion to favor lowest-common-denominator languages features and shun high-utility but "complex" ones.

That is a real shame, however. As a business or whatever, instead of maximizing for ease of onboarding, I want to maximize for facility in exploring the end-goal problem domain, i.e. expert work. Instead of picking a "readable" language, I want to pick one that increases our ability to find simple solutions to complex-seeming problems, conventionally readable or not.

IMHO, baseline languages like Python are great for writing down what you already think but terrible for iterating on your understanding, and 95% of our work as engineers is (should be?) changing our understanding of the problem to fit reality as it bumps us in the face.

Re: Rust's Ugly Syntax (2023)

#99

Post by mrweasel »

kitkat_new wrote: post #93
jeroenvlek wrote: post #89

Earlier quoted context omitted.

A lifetime keyword would actually go a long way in improving ergonomics. You could even make it synonymous with '. Then people can choose. Maybe one will get much more traction and the other can be deprecated.

why? It makes type information unnecessarily longer without adding information, and feels like writing "end_stm" instead of ";" after every line

That's the trade off isn't it. ' is unnecessarily short and doesn't convey any information at all, or worse, the wrong information. There are other comments that point out that ' is valid in identifier, or used to indicate that something is derived from something else.

Some will prefer the short nature of just typing ', where people like me would prefer that you just add a few more characters so it reads more easily.

Post reply on HN