4 ms·

I really wanted to give Rust a chance for the memory management but I just don't have the motivation to get past the absolutely bizarre syntax, naming conventio

I really wanted to give Rust a chance for the memory management but I just don't have the motivation to get past the absolutely bizarre syntax, naming conventions full of weird abbreviations like it's the 80s, and the inscrutable replacement for the OO everyone is familiar with. Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once.

steveklabnik 7y ago
Almost all of these things come from other languages, some that have existed for decades. It's probably unfamiliar because you haven't run across them yet, which is fine!
- deleted 7y ago
  [deleted]
vmchale 7y ago
> Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once. Not really, a lot of things are taken from sensible theory (e.g. traits and typeclasses).
skykooler 7y ago
Coming from Python, Rust feels like C++ with a stricter compiler. It depends on how you look at it.
wrs 7y ago
> an exercise in NIH syndrome Don't fall into the trap of thinking the entire world is like what you can see from where you're standing. It's not really "not-invented-here", it's "not-invented-there", where "there" is wherever you're used to being. There aren't many unprecedented ideas in Rust.
simias 7y ago
A lot of the syntax was borrowed from C++ for better or worse. It does make the transition from C++ a lot easier but of course if you're not familiar with the language there'll be some friction. Beyond that there are things that Rust needs syntax for that simply doesn't exist in many other languages such as the Trait-based generics, modules (that didn't use to exist in C++) and of course lifetimes. Beyond that I can't help but feeling that you're following this (IMO) counterproductive cargo cult that holds that sigils are teh 3v1l and everything should be alphanumeric only. Python was at the forefront of this movement but it's now very popular. IMO it's completely counterproductive, even in Python case. It's form over function. You end up with a language where you have to be careful when you refactor because indentation becomes significant and no way to scope your variables properly. Or a language like JS where somebody genuinely thought that having arcane rules to automatically insert semicolons was a reasonable idea because "ewwww semicolons look ugly". It sure looks good if you want to get them tatooed, but in practice at best it's pointless and at worst it gets in the way. I'm all for descriptive variable and function names but the core syntax of the language is repeated all over the place all the time and benefits from concision. Having Rust spell out "function" instead of "fn" wouldn't disambiguate anything since you're exposed to it within 5 minutes in the language and you'll be super familiar with it very quickly. Having a shorthand means that it doesn't pollute the code listing and leaves more room for the actually important stuff. A lot of people like to point out Perl as an example of "sigil soup gone wrong" but I'd argue that it's not even the real problem here, Perl can become an unreadable mess because of all the "magic" it allows, meaning you can write code that seems to do absolutely nothing but actually does a whole lot (with things like the implied variable $_ for instance). If you look at an exhaustive list of Perl operators there are only a handful I'd personally consider questionable (like `x` and maybe `<=>`. Also some of the quoting q{} qq{} and qx{} are really obtuse).
empath75 7y ago
i actually really enjoy the syntax and trait system and dislike the memory management stuff -- i'd rather have the rust syntax in more of a scripting language. It's a joy to write rust code for the most part.
nicoburns 7y ago
Bizarre syntax? It's almost identical to JavaScript/TypeScript syntax. You know, the #1 most used language.
- jimmaswell 7y ago
  JS, C++, C# are what I'm coming from. There was no need to put things in strange orders and otherwise do so many other things different from C style for no apparent reason. Sure, you can find some example of another language doing something any way, but that doesn't make it a good idea. What tangible benefit is there to having to put the type after the function declaration?
  - TheDong 7y ago
    You've given one concrete example, the type after the function deceleration. I'll respond to that because there is a concrete benefit. For what it's worth, typescript, go, SML, haskell, and many other languages follow this pattern too. In C, there's the "clockwise spiral rule"[0] to read a complex c declaration. Let's take an example from that: void (*signal(int, void (*fp)(int)))(int); In rust, that would be: fn signal(i: isize, fp: Fn(isize) -> ()) -> Fn(isize) -> () In rust, the clockwise spiral rule is more simply the "read left to right" rule, which follows more naturally for most people. For what it's worth, C++ also includes alternate function syntax [1], which matches rust's ordering of return values. The reason it was added to C++ is because there were actual expressions the old syntax could not unambiguously express. Even to a machine the C-style declaration is more confusing. With no offence meant, you're sounding a little blub[2]-ish in that complaint. [0]: http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html [1]: https://en.wikipedia.org/wiki/C++11#Alternative_function_syntax https://en.wikipedia.org/wiki/C++11#Alternative_function_syn... [2]: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
    - jstimpfle 7y ago
      The spiral rule is wrong (or at least overcomplicated). There was once a guy who didn't understand how C declarations work, so he made some guesses, put them on his webpage, and then he still didn't know how declarations work! Too bad this page got so popular. What he did was essentially he discovered precedence rules for normal C expressions. That's all. https://news.ycombinator.com/item?id=22451431 https://news.ycombinator.com/item?id=22451431

steveklabnik 7y ago

Almost all of these things come from other languages, some that have existed for decades. It's probably unfamiliar because you haven't run across them yet, which is fine!

deleted 7y ago
[deleted]

vmchale 7y ago

> Every facet of the language feels like an exercise in NIH syndrome and it's just too much at once. Not really, a lot of things are taken from sensible theory (e.g. traits and typeclasses).

skykooler 7y ago

Coming from Python, Rust feels like C++ with a stricter compiler. It depends on how you look at it.

wrs 7y ago

> an exercise in NIH syndrome Don't fall into the trap of thinking the entire world is like what you can see from where you're standing. It's not really "not-invented-here", it's "not-invented-there", where "there" is wherever you're used to being. There aren't many unprecedented ideas in Rust.

simias 7y ago

A lot of the syntax was borrowed from C++ for better or worse. It does make the transition from C++ a lot easier but of course if you're not familiar with the language there'll be some friction. Beyond that there are things that Rust needs syntax for that simply doesn't exist in many other languages such as the Trait-based generics, modules (that didn't use to exist in C++) and of course lifetimes. Beyond that I can't help but feeling that you're following this (IMO) counterproductive cargo cult that holds that sigils are teh 3v1l and everything should be alphanumeric only. Python was at the forefront of this movement but it's now very popular. IMO it's completely counterproductive, even in Python case. It's form over function. You end up with a language where you have to be careful when you refactor because indentation becomes significant and no way to scope your variables properly. Or a language like JS where somebody genuinely thought that having arcane rules to automatically insert semicolons was a reasonable idea because "ewwww semicolons look ugly". It sure looks good if you want to get them tatooed, but in practice at best it's pointless and at worst it gets in the way. I'm all for descriptive variable and function names but the core syntax of the language is repeated all over the place all the time and benefits from concision. Having Rust spell out "function" instead of "fn" wouldn't disambiguate anything since you're exposed to it within 5 minutes in the language and you'll be super familiar with it very quickly. Having a shorthand means that it doesn't pollute the code listing and leaves more room for the actually important stuff. A lot of people like to point out Perl as an example of "sigil soup gone wrong" but I'd argue that it's not even the real problem here, Perl can become an unreadable mess because of all the "magic" it allows, meaning you can write code that seems to do absolutely nothing but actually does a whole lot (with things like the implied variable $_ for instance). If you look at an exhaustive list of Perl operators there are only a handful I'd personally consider questionable (like `x` and maybe `<=>`. Also some of the quoting q{} qq{} and qx{} are really obtuse).

empath75 7y ago

i actually really enjoy the syntax and trait system and dislike the memory management stuff -- i'd rather have the rust syntax in more of a scripting language. It's a joy to write rust code for the most part.

nicoburns 7y ago

Bizarre syntax? It's almost identical to JavaScript/TypeScript syntax. You know, the #1 most used language.

jimmaswell 7y ago
JS, C++, C# are what I'm coming from. There was no need to put things in strange orders and otherwise do so many other things different from C style for no apparent reason. Sure, you can find some example of another language doing something any way, but that doesn't make it a good idea. What tangible benefit is there to having to put the type after the function declaration?
- TheDong 7y ago
  You've given one concrete example, the type after the function deceleration. I'll respond to that because there is a concrete benefit. For what it's worth, typescript, go, SML, haskell, and many other languages follow this pattern too. In C, there's the "clockwise spiral rule"[0] to read a complex c declaration. Let's take an example from that: void (*signal(int, void (*fp)(int)))(int); In rust, that would be: fn signal(i: isize, fp: Fn(isize) -> ()) -> Fn(isize) -> () In rust, the clockwise spiral rule is more simply the "read left to right" rule, which follows more naturally for most people. For what it's worth, C++ also includes alternate function syntax [1], which matches rust's ordering of return values. The reason it was added to C++ is because there were actual expressions the old syntax could not unambiguously express. Even to a machine the C-style declaration is more confusing. With no offence meant, you're sounding a little blub[2]-ish in that complaint. [0]: http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html [1]: https://en.wikipedia.org/wiki/C++11#Alternative_function_syntax https://en.wikipedia.org/wiki/C++11#Alternative_function_syn... [2]: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - jstimpfle 7y ago
    The spiral rule is wrong (or at least overcomplicated). There was once a guy who didn't understand how C declarations work, so he made some guesses, put them on his webpage, and then he still didn't know how declarations work! Too bad this page got so popular. What he did was essentially he discovered precedence rules for normal C expressions. That's all. https://news.ycombinator.com/item?id=22451431 https://news.ycombinator.com/item?id=22451431