Hacker News Reader

Comment by w8rbt | Hacker News Reader

I agree 100%. The Rust syntax is so different from C, C++, Go and Java that it's very difficult for me to use. I love the idea of Rust, but I wish the syntax was more similar to traditional languages. If it were, I think it would be a very easy transition for many of us.

View on HN

That...seems very surprising to me. I've used almost exactly the same set of languages, and I found the Rust syntax incredibly familiar. There are times when (especially if you use a lot of boxing and ref-counting) that you can get a touch of operator soup, but that's not that often. Anyways, the languages feel very similar to me.

A lot of the compromises made in Rust syntax were to make it much, much easier for the compiler to reduce passes to compile into a syntax tree.

There are certainly some things that should just be obvious now, though. Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol, using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) And the syntax for lifetimes is horrible, with the 'a and the fact that in practice its about as significant as naming parameters in a C++ function definition in a header (ie, pointless - the words are discarded by the compiler every time).

And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam.

Given all that, Rust is still, IMO, the best programming language we have right now for native performance, period. We can criticize what we don't like but we should at least agree its the best we have.

> Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol

Obtuse? It's sort of common. Multiple languages use it. Personally I like the namespace separator being distinct from the object/struct element accessor. At least they didn't copy PHP in using backspace...

> using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.)

Please, let's not have more cases where things look like functions but aren't. Functions should look like functions. Operators should look like operators. You might have to learn a small set of operators for a new language. This is front-loading some confusion and learning pain for ease of use later. It may make the language harder to read for people that don't know the language, but anyone reading the source code with the aim to make some changes should probably know the operators at least. I'm not sure giving it a slightly more expressive name but making it look like something else actually makes life easier for those people.

> And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam.

Optional whitespace significance? That sounds like a recipe for disaster, IMO. I can see a case for one or the other, but mixing of modes like that when it deals with something that is by nature somewhat invisible (or meta), seems prone to problems.

Also, examining why Python has had problems with functional style workhorses like map might shed some light on the negative aspects of whitespace dependent syntax.

Commonality doesn't make a shift-accessible character twice in a row less obtuse. It is like if < and > were the bitwise shifts and >> and << were the logical - it would make no sense because the more common behavior was using more characters.

Of all the glyphs used in the language, :: is probably in the top 5 for frequency of use (probably higher than even * in Rust, considering the infrequency of pointer usage and that multiplication isn't that common an operation in general code) but uses two glyphs instead of one.

It would have required different design constraints starting out to figure which glyph would be best suited instead of ::, but :: is still really ugly in all the languages that use it when its such a common symbol. I wouldn't argue overloading . is right, but I'm having a hard time seeing why a single colon doesn't work - foo:bar:baz. Maybe the parser finds scoping and explicit type names on definitions (ie let foo: i64 or in function definitions) require too many passes to distinguish?

Valid points. A single colon would suffice, but I suspect in C++ they wanted something a bit more distinct from the semicolon. For Rust, I imagine at least part of the reasoning was keeping with what was familiar wit h C++, and after that the type names probably did make it complex, if not intractable (without reserving specific names).

Lots of languages with whitespace significance have no ergonomic issues with functional style. Haskell and the ML family come to mind.

Actually, looking at Haskell, the optional whitespace (either indentation or braces, newline or semicolon) looks like it solves that problem quite well. I don't have much experience with optional whitespace, so I can't comment on whether it neatly solves the problem, or creates additional problems in readability as close to or greater than the original problem. My gut feeling is still that it might be messy.

Agree that making keywords look like functions is weird and bad, but I also loathe languages that insist on using special chars for things that are better expressed with words. C# is my daily driver and I like how it calls pass-by-reference stuff "ref". And likewise, while I can see the appeal of making namespace and member lookups distinct, I've never liked the readability of C++ :: syntax, and I learned C++ fairly early on in my career.

> C# is my daily driver and I like how it calls pass-by-reference stuff "ref".

`&` isn't a parameter annotation in Rust, it's two unary operators, two type annotations (general) and a pattern-matching operator.

The latter of which `ref` also is, incidentally, it means "capture a value by reference" in a pattern: https://play.rust-lang.org/?gist=30b436d83701f74b986aea978fa... (& meaning "capture a reference by its target" in that context, which is logically the structural inverse of the operator)

Backspace would be amazing in Rust. Imagine:

    use .\greetings\hello;
    use ..\foo;
    use \bar;

right now these are:

    use self::greetings::hello;
    use super::foo;
    use ::bar;

I think the PHP way would have been way better

Backslash is almost universally associated with "escaping" the next character in a string. The only place I've ever seen it used as a separator is in Windows, and my understanding is that it causes enough grief when used in strings that people dislike it there as well. The only reason Windows uses backslash is because DOS 1.0 didn't have hierarchies and already used slash for command switches, so they used backslash so it wouldn't conflict.

What is wrong with ::? It's visually distinct, isn't easily confused for other things, and unused for anything else, which pretty much hits all the criteria I care about for this feature.

I'm seriously asking, why do people dislike ::? Is there an actual basis, or do people just not like the look?

Those paths are actually valid Windows paths. I don't like `super` and `self` instead of `..` and `.` - it's just extra stuff to remember.

Also, because of how the metaphor for paths is broken, the relative paths in Rust are not intuitive. That's why you HAVE TO put `self::foo` because the default is not the same as what you'd expect if it were a path.

It's overly complicated compared to just letting you use actual Windows paths.

Except not everyone uses Windows. Why not a regular slash instead of a backslash since even on Windows they sometimes allow that since it's standard for the web? Because modules and namespaces don't always correspond to files. Having the namespace separator be the same as a file path separator may imply a connection to the the filesystem hierarchy which does not exist, or is far removed.

> Why not a regular slash

because how do you parse

    let x = a/foo();

is that a::foo() or a / foo()?

If you use \ it's unambiguous, a\foo() corresponds to a::foo() while a/foo() is division

Exactly. Forward slash has problems. Backslash has problems. Associating the concept with file paths too much has problems (depending on the language and the module implementation).

So, why again is :: such a bad choice, given all this?

Backslash does not have problems. It's a single character and looks like windows paths. :: is two characters and is only familiar for C++ programmers (and means something else in PHP)

Backslash is the single most problematic visible character to represent in lower ASCII. It's the go-to solution for representing the non-visible characters when you need them in a string representation in most languages I can think of. Many errors have been found in string handling routines because of incorrect escape handling. I wouldn't willingly use it as a special character in any language I had input in designing.

Even for windows paths, backslash has caused a lot of problems in various tools[1][2][3]. Just google "backslash path error" for many pages of problems. Even early DOS developers weren't happy with the need for backslash, and made regular slashes work in paths. That doesn't work everywhere in Windows, but it works in a lot of places. Following Microsoft's mistake because of an accident of history (they has already used forward slash for command flags before implementing path hierarchies so needed a different character) and dealing with the same problems they have is not a point in backslash's favor.

> :: is two characters and is only familiar for C++ programmers

It's familiar for whoever learns it for the language they are learning. That it does not necessarily have an association with concepts from other languages or systems that don't apply cleanly (such as the namespace corresponding to the path, which may not be true) is a positive.

1: https://pythonconquerstheuniverse.wordpress.com/2008/06/04/g...

2: https://github.com/rstudio/shiny/issues/1009

3: http://www-01.ibm.com/support/docview.wss?uid=swg21635233

That's \ inside of paths and strings. Nothing to do with \ used in a language. Nobody has an issue with \ used in PHP. The only problem is maybe pasting code on a blog or something, not really a problem when programming in PHP.

Everything eventually gets represented by a string somewhere. Paths aren't inherently strings, but that's how they are often represented in code. You won't be defining your namespaces as a string in normal usage, but some things do need oto represent source, so why choose a character that makes their jobs harder. There are parallels. It's a downside of using backslash. It's not guaranteed to cause a problem, but the potential is there and waiting for anyone that needs to deal with representing it in language.

By string, I of course speak of string literals. The only place where this would be an issue is writing Rust compiler error messages. I don't consider that a strong argument for why the path analogy should be broken. Because the path analogy is broken, modules in Rust have strange rules. For example,

    use foo::bar;

doesn't actually use a relative "path" from the current module

you need to use

    use self::foo::bar;

I think this is a confusing default, and it would have never ended up this way if Rust used Windows-path-looking namespace syntax

if you're writing a parser and manipulating actual arrays of bytes, you don't have an issue with backslash, it's just another character to you

> I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.

Ugh, no. There are references all over the place when I write Rust code -- it would be a serious bummer for me if annotating those types and making those references took up 4 characters for "ref " instead of just the 1 for &.

You can have both, but you use a lot of vocabulary all the time in rust (clone, let, mut, static) and nobody is harping on how the most common words need to be made glyphs to save 2-3 characters per use.

I'm curious: what is so different about the syntax? It seems very similar to me.

I think the thing that puts me off the most is the lifetime specifiers:

  let foo:'static str = "foo";

Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. Just like for parentheses; imagine how confusing it would be if ' would have been ( instead.

  let foo:(static str = "foo";

This particular convention is inherited from the ML family, where it has been very popular for a very long time.

For what it's worth, there are many cases even in the natural language where ' is not supposed to have a "closing" counterpart - indeed, the "it's" in this very sentence is one such example. Then you have the use of ' to denote feet and minutes of arc. Now, technically these are all actually different symbols, with their own Unicode codepoints etc - but in practice, people use ' for all of them, and it doesn't seem to be confusing anyone. You could treat the ' in Rust as something along these lines.

> Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing.

In fairness, you should never be searching for matching apostrophe. Single quote, maybe. The fact that it's an apostrophe should also trigger that it might have something to do with possession... (or that something was omitted).

Granted, lifetime syntax has no analogue in the languages the comment I was replying to mentioned. That doesn't seem to be enough to qualify as "so different" though. But maybe it is?

The syntax is really on the same as C-Style languages, minus the extra lifetimes bits.

Reply on news.ycombinator.com