Hacker News Reader

I know nothing about rust, but what are you actually complaining about here? The only additional "sigil" in the rust example is the & for vector which I assume marks a reference. Languages that confuse objects with references are a pet peeve of mine, so good for rust to mark the difference. : vs -> and type[] vs [type] are just preferences, neither is obviously better. The Vec2 declaration in the first example actually has more sigils than the rust example (= and ;).

Regarding shorthands, just number would be unacceptable for 99% of the work I do, and it would be something that specifies signedness, integer vs float and size. As a c++ programmer, having to write std::uint64_t gets old very quickly and I'm happy that rust uses a shorter name for these.

I don't think that using a shorthand for something very common is an hindrance to comprehension. Do you think one should write "have not" instead of "haven't" in English?

> Do you think one should write "have not" instead of "haven't" in English?

Given how many people do this wrong? Yes, that sounds like a great idea.

I have to agree with OP that Rust often looks like sigil soup. The example isn’t great, but there is a _lot_ of noise when looking at Rust code. Of course they all have a meaning, but I feel sometimes that meaning could be more easily expressed as a verb than a sigil. At least it would make things more readable (until you get into generics I think Typescript scores pretty high on readability).

> Of course they all have a meaning, but I feel sometimes that meaning could be more easily expressed as a verb than a sigil.

Why not try to come up with an alternate syntax, expressing everything in English-like verbs and compiling into Rust proper? You could call it RUBOL. Then #[RUBOL] code fragments could even be supported within .rs files

Not a bad idea. I may see if that makes Rust more palatable.

> Wow. Listen: code written in languages heavy with sigils and shorthand are hard to understand, read and most importantly: maintain.

As someone who maintains a 145k line Rust codebase all on his own, I have to hard disagree on this one.

Once you get used to the syntax it just blends into the background and becomes a non-issue.

> This adds a mental load which is -- as clearly visible from above -- is totally unnecessary.

Totally unnecessary? Okay, so how would you do the following with the sigilless syntax (and disambiguate between them):

- Specify a unique reference? (`&T` is shared, `&mut T` is unique)

- Specify a lifetime? (`&'a T` is a reference to T with lifetime `a`)

- Specify a raw pointer? (`*const T` and `*mut T` are const/non-const raw pointers)

- Specify that the argument is moved into the function? (just the raw type `T`)

People have been trying to come up with a better syntax for Rust, and AFAIK so far nobody has been able to do it. There's always a tradeoff somewhere that ends up making matters worse than what we have now.

> Specify a unique reference? (`&T` is shared, `&mut T` is unique)

shared T

shared mut T

> Specify a lifetime? (`&'a T` is a reference to T with lifetime `a`)

shared T lifetime a

> Specify a raw pointer? (`const T` and `mut T` are const/non-const raw pointers)

const point T

point mut T

> Specify that the argument is moved into the function? (just the raw type `T`)

T

While this may be better in retrospect, it doesn't mean it's how Rust should have been. Rust was designed to replace C++, so using more C++ was probably the right call to get people to consider it more.

I do disagree on the syntax for the references though. I prefer they be easier to type than the owned versions (eg &[u8] vs Vec<u8>) as this can promote the usual better choice (this is a weak argument, I acknowledge).

I do wish that history had chosen a different symbol for references though. But there's only so much we can do now

Interesting idea, but honestly that seems too far in the other direction. A midpoint between the two ends that optimizes both brevity and readability is probably ideal.

If you view Rust as a high-level language, then yes, there's probably a slight overload of sigils, operators and characters. However, Rust was not outright designed to replace languages like Python, Java or JavaScript but systems level languages like C++. Given that is has no runtime and a fair few compile time guarantees, as a programmer you need to tell the compiler explicitly what something is and how it is owned. If you come from a language with a runtime and start using Rust as if it is another high-level language you will hit the borrow checker wall at some point.

You could also write the function above as `fn avg_len(vecs: Vec<Vec2>) -> f64 {`, and I personally would write the TS one as `const avgLen = (vecs: Array<Vec2>): number`. However, there's a difference between the ownership of a `Vec` and `&[]`, something a language like TS doesn't need to worry about but Rust does.

Perl was a vastly more complex language than Rust. It was literally trying to build something with the complexity and ad-hoc features of natural language out of random symbols. It's not surprising that it didn't work very well.

The more complex the underlying semantics you're working with, the more verbose and less symbol-driven your language should be. You can see this clearly with things like COBOL, which tried to integrate every feature that might ever be needed for business programming within its base language - a staggering amount of complexity. English-like syntax kept that workable.

I don't mind venting at all, but don't agree.

> This adds a mental load which is -- as clearly visible from above -- is totally unnecessary

For numbers in Typescript you basically have a number type (there is also that story about BigInt, but...) - this is as good as Rusts f64

In Rust you have: u8, u16, u32, u64, u128, i8, i16, i32, i64, i128, f32, f64

Sure, you could have some kind of alias number = f64 - but why? Rust and Typescript have different uses.

For the web, number (f64) is good enough. If you do system programming then you need some options.