4 ms·

These two lines are worth looking at because they showcase why I am not really fond of Rust as much as people who would rewrite everything from the Linux kernel

by chx 5y ago

These two lines are worth looking at because they showcase why I am not really fond of Rust as much as people who would rewrite everything from the Linux kernel to the IMF in Rust if they could (which in itself is seriously off putting if my tone didn't tell you that): type Vec2 = { x: number, y: number }; function avgLen(vecs: Vec2[]): number versus: struct Vec2 { x: f64, y: f64 } fn avg_len(vecs: &[Vec2]) -> f64 { There has been more than two decades between the release of Perl and Rust and you haven't learnt anything? Wow. Listen: code written in languages heavy with sigils and shorthand are hard to understand, read and most importantly: maintain. This adds a mental load which is -- as clearly visible from above -- is totally unnecessary. I have no idea why would anyone in 2010, several years after the famous "memory is the new disk, disk is the new tape" do this to save on characters in the source code. The teletype is a distant memory. Thanks for letting me vent a little.

mhaberl 5y ago
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.
sondr3 5y ago
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.
gpderetta 5y ago
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?
- Aeolun 5y ago
  > 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).
  - zozbot234 5y ago
    > 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
    - Aeolun 5y ago
      Not a bad idea. I may see if that makes Rust more palatable.
kouteiheika 5y ago
> 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.
- Aeolun 5y ago
  > 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
  - conradludgate 5y ago
    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
  - iamthemalto 5y ago
    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.
zozbot234 5y ago
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.

by chx 5y ago

mhaberl 5y ago

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.

sondr3 5y ago

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.

gpderetta 5y ago

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?

Aeolun 5y ago
> 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).
- zozbot234 5y ago
  > 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
  - Aeolun 5y ago
    Not a bad idea. I may see if that makes Rust more palatable.

kouteiheika 5y ago

> 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.

Aeolun 5y ago
> 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
- conradludgate 5y ago
  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
- iamthemalto 5y ago
  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.

zozbot234 5y ago

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.