Rust's Ugly Syntax (2023)

It's worth pointing out here for people not familiar with Rust, that this is the result of code generation by a third party crate to enable async methods on traits.

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 obviously, but why not simply have the developer prefix the variable with the keyword "lifetime", rather than assigning a symbol. It seems a little like starting functions in Go with a upper case letter to export them, dude just give us an export keyword, it's fine.

> https://mirror.whynothugo.nl/vdirsyncer/v2.0.0-beta0/vstorag...

Unrelated to parent but maybe relevant to you: Rust API naming guidelines say no `get_` prefix on getters.

https://rust-lang.github.io/api-guidelines/naming.html#gette...

or just

    async fn list_items(&self, colletion_href: &str) -> Result<Vec<ItemRef>, Error>

I always describe it to myself this way - T: Foo means T is a superset of Foo (because it at least implements Foo but most likely more) thus 'a: 'b means 'a is at least as wide as 'b, and possibly wider

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.

I am reminded of many instances over my life of:

1) Every time I go through a particular door I try to push it when it's a pull door.

2) I notice this and ensconce in my brain that it's the opposite of what I think it is.

3) After a while, my brain actually starts to remember it the correct way around to start with.

4) But my brain doesn't then drop the 'opposite' rule so now I remember it the correct way around, then invert it, thus recreating step 1.

I don't claim this says anything about rust, but I think it does say something about human brains (or at least mine and apparently yours).

My sympathies.

If you think of it as 'a implements b', it makes sense for both lifetimes and (other) subtypes: If lifetime `a` implements `b`, it is obviously valid for `b` (and maybe longer).

You have to first remember what lifetimes are there for in the first place: to indicate that values live at least a certain duration. That is what the type &'a means. Then it becomes clear what the relation 'a: 'b means

In lifetime, subtype means longer lifetime (it's unintuitive). 'a : 'b means 'a is a subtype of 'b, which contains 'b and can be longer.

Rust can improve this by introducing syntax like `'a contains 'b`

It was a good signal to me that you are overthinking into the architecture if that is really required. Rust makes something pretty much impossible in C/C++ possible, but not necessarily easy, and that would be one such example.

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.

It's not necessarily identical to what you are looking for per se but a mix of C# and F# will be the closest overall to Rust in terms of performance, access to systems programming features, language expressiveness and tooling experience.

Cons are:

- C# has OOP (you don't have to use it heavily)

- No Hindler-Milner type inference in C#, nested generic arguments may need to be specified by hand

- Smaller amount of supported targets by CoreCLR: x86, x86_64, arm, arm64 for ISAs and Linux, Windows, macOS and FreeBSD for OSes. NativeAOT-based support is experimentally available on iOS, and is undergoing further work. As you can imagine, LLVM targets absolutely everything under the sun and above it too. no-std story in Rust is first-class. C# has bflat and zerosharp but they are niche.

- In C#, type unions will only be available in one of the coming versions. F# to the rescue

- Error handling is a combination of exceptions and e.g. int.TryParse patterns, there is no implicit returns with ? like in Rust

- Lack of associated types and the types own their interface implementations unlike traits which you can introduce without control over the source. This results in having to implement wrapper types (even if they are structs) if you want to modify their interface implementations

- You only control shallow immutability - readonly struct will not prohibit modification of the contents of a Dictionary<K, V> that it holds

- async/await is more expensive

- Big popular libraries often have features or implementation incompatible or not guaranteed to work with native compilation via NativeAOT

- Object reference nullability (e.g. 'T?') happens at the level of static analysis i.e. does not participate in type system the same way Option<T> does in Rust

Pros are:

- Has FP features like in Rust: high order functions, pattern matching (match val -> val switch { , also 'is'), records, tuples, deconstruction

- Fast to compile and run, AOT not so fast to compile but tolerable

- If you know how to use Cargo, you know how to use .NET CLI: cargo init -> dotnet new {console, classlib, etc.}, cargo run -> dotnet run, cargo build -> dotnet build/publish, cargo add {package} -> dotnet add package {package}

- Monomorphized structs generics with the same zero-cost abstraction assurance like in Rust, &mut T -> ref T, &T -> ref readonly T, sometimes in T but with caveats

- Box/Arc<T> -> class or record, Arc<Mutex<T>> -> class + lock (instance) { ... }

- Easy to use async/await but without ever having to deal with borrow checker and misuse-resistant auto-scaling threadpool. Task<T>s are hot started. Simply call two task-returning network calls and await each one when you need to. They will run in background in parallel while you do so. While they are more expensive than in Rust, you can still do massive concurrency and spawn 1M of them if you want to

- Built-in Rayon - Parallel.For and PLINQ, there is Channel<T> too, you can e.g. 'await foreach (var msg in chReader) { ... }'

- Iterator expressions -> LINQ, seq.filter(...).map(...).collect() -> seq.Where(...).Select(...).ToArray(), unfortunately come with fixed cost but improve in each version

- Rust slice that wraps arbitrary memory -> Span<T>, e.g. can write the same fast idiomatic text parsing on top of them quite easily

- Stupid fast span routines like .IndexOf, .Count, .Fill, .CopyTo which use up to AVX512

- Compiler can devirtualize what in Rust is Box<dyn Trait>

- Can make small native or relatively small JIT single-file executables that don't require users to install runtime

- Rich and fast FFI in both directions, can statically link into Rust, can statically link Rust components into itself (relatively new and advanced)

- Great tooling, Rider is very good, VSCode + base C# extension about as good as rust-analyzer

- Controversial but powerful runtime reflection and type introspection capability, can be used in a very dynamic way with JIT and compile additional code on the fly

- A bit easier to contribute to, depending on area owner and project (runtime, roslyn, aspnetcore, ...)

- CoreLib has full-blown portable SIMD API that is years ahead of portable-simd initiative in Rust

Because I occasionally use Rust and prefer its formatting choices, I carry this .editorconfig around: https://gist.github.com/neon-sunset/c78174b0ba933d61fb66b54d... to make formatting terser and more similar. Try it out if K&R and `I` prefix on interfaces annoy you.

check out Google’s Carbon :)

Scala

The author explains it in the first sentence, i.e. not the syntax of lifetimes may be your problem, but the feature itself

My reading is: people use Rust because it’s fast but then they complain about the semantics that make it fast.

In other words, be careful what you wish for.

Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity. However, once you deviate from the goal of “as fast as possible”, then you have to choose which parts you want to sacrifice speed for productivity. Like Excel, everybody agrees that Rust is too complicated but nobody can agree on which 10% to remove.

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

It ends in ";;". If that's not a typo, and it's semantically significant that there are two semicolons instead of one, that sounds quite finicky.

I think he's referring to Python, just like other made up names probably refer to Java, Js, C++ and OCaml.

This. In general, standard library is a poor example as it has to serve very wide range of scenarios, be robust to many environmental conditions when IO is involved and perform optimally. If it's terse enough while doing so, it's good enough already.

well no need for the sub wrapper really

  say $path.IO.slurp: :bin

> C++ is relatively easy to read

Only if you suffer from a very high level of stockholm syndrome, that is. Rust's syntax is vastly clearer than C++ in basically all circumstances.

I love async Rust. Its implementation is marvelous. Sueper plasant to write now that

* async closures

* async trait fns,

* `impl Trait` everywhere

are in place.

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.

Huh. My brain says logically I should find that better, but the -lack- of punctuation is making it really tricky to skim read the way I do most languages.

I'm not arguing the example you found sand-in-the-eyes is necessarily good but my mental skim reading algorithm copes with it much better.

Do you think C++ programmers are incapable of learning a language without braces?

Why? You can easily find parameter names in the signature if you just put them on separate lines. For me there's very little reason of putting them all together on separate line after the signature. And then when you look for a type of a parameter you know the name of, it gets difficult.

Original code contains more. (::). Personally I don't understand why there are `::` and `.` to access deeper namespace levels. It's a static language, compiler should know how to resolve attributes and `.` should be enough for all cases.

    pub fn read(path: Path) -> Result<Bytes> {
      File::open(path)?.read_to_end()
    }

Throw an exception

proving the point of the article even further

Is it harder to understand than when to put lambda: in Python code?

Definitely agree, “pub” was one of the design decisions I loved learning Rust. If you forget to add it, you’ll get a compiler error. But if pub was default, I’d be exposing code unnecessarily. And no need for a separate private keyword, the absence of pub is sufficient.

The same reasoning works for “mut” as well.

That said, I don’t like Rust’s syntax. Especially once you get to lambdas, things get hard to read.

> If public were the default, you'd end up having to make other functions `priv fn` instead.

My guilty pleasure is Go's visibility system, where all functions that start with lowercase are private to the scope of the current class/file and all Functions that start with Uppercase are public.

It doesn't look but it would work and it's a mess when you need acronyms, but it somehow works great and the result looks nice.