8 ms·

It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons. Some compromises had to be made, e.g. the lack of tailcalls

• alcuadrado 13y ago
  Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \ you \ to \ write \ so \ many \ backslashes. They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story. Disclaimer: I code python every day of my life nowadays, I'm not a python hater.
  • jerf 13y ago
    I've written a lot of Python too. When I need to span lines, usually there's an easy way to use parens to do blahblah = long().invocation_of.something(with, lots, of, parameters) which is generally more idiomatic. (Of course one wishes to avoid long lines at all but that's not always possible.)
    • alcuadrado 13y ago
      I found that parnes rule used as an awful hack a lot of times. I use it only when the parens are naturally placed, but there are people that just add two parens to avoid one backslash... completely insane!
      • kzrdude 13y ago
        How is the backslash better? The parantheses can stay if you join two lines or split them.
        • loqi 13y ago
          Yup, and parens also allow comments.
  • jboy 13y ago
    I type many, many more semicolons in C or C++ than I type line-continuation backslashes in Python, so I prefer the option that requires fewer keypresses and less syntactic noise. Or to put it another way, I'd much rather have to syntactically announce a line-continuation (which happens rarely, and is thus an atypical event that is worthy of note) than announce the end of a statement (which happens every single statement, and is thus to me much less worthy of note). My reasons for preferring indentation-as-block over brace block-delimiters are similar: The indentation is a much more subtle, unobtrusive, un-noisy alternative to braces. Furthermore, when I code in C or C++, I indent (and brace-delimit) everything properly, according to a style guide; so if I'd be indenting the block anyway, why not make the indentation syntactically meaningful, to save me some keypresses and slightly decrease the syntactic noise? Plus, for bonus points, brace-less blocks mean I never need to play the brace-matching game. ("Have I got an extra/missing brace in there somewhere? Put the cursor on the brace and tap `%` until I work out what's out of place." True, it doesn't happen frequently if you keep your blocks and functions small, but I'm quite happy to avoid it altogether.)
  • lobster_johnson 13y ago
    I prefer Ruby's approach, which is not whitespace-sensitive, but has a very liberal approach to where expressions end. The general rule is, as with Python and Go, that open braces, brackets, parens or quotes have precedence; and operators or punctuation at the end of a line will continue to the next line. In addition, there are some complicated parsing internals -- not just for expression-ending sensing, but also for supporting parens-less method calls -- that endow the parser with some compiler knowledge about what tokens are variables and what tokens are methods. In other words, the parser has information that violates the parser/compiler separation of concerns, but it works really well in practice. The only time I ever use \ in Ruby is for string literals that need to be broken up for readability: my_string = "This is a very long string that" \ " must be wrapped." You can use + or <<, but this will be evaluated at runtime, whereas \ results in a single string allocation. Of course, Ruby requires "end" for a lot of constructs, but it could have just as well have used braces.
    • gnaritas 13y ago
      Ruby can use braces instead of end, both are valid.
      • lobster_johnson 13y ago
        Hm? Only for blocks. Not classes, methods, if/unless, while or begin/rescue.
        • gnaritas 13y ago
          Dang, you're right, I could swear otherwise but yup, just on blocks.
  • rdtsc 13y ago
    if you put a backslash on every line in Python, check your code, variable names. I rely more on splitting on tuples or dictionary items. So you can actually write like this: (forces, you, to, ... )
• kibwen 13y ago
  The standard indentation style is four spaces. Rust does have a pretty-printer (think gofmt), but it's not very good right now so it never actually gets used. It's very old and basically needs to be entirely rewritten.
• coldtea 13y ago
  >It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons. Yes, it's childish. Worse, it's bikeshedding.
  • Dewie 13y ago
    I think it's reasonable to complain and openly discuss comparatively minor issues when a language hasn't even reached 1.0, since it's at that point a prime time to iron out everything that might be an annoyance later.
  • zepolud 13y ago
    Defining a sane syntax while the language is still in its infancy is anything but bikeshedding. You have only one chance to do it right before an entrenched codebase develops or interest in the language fizzles. MS Research did this right with the experimental hardwhite support while F# was still in alpha. People liked it so much that it became the default style for the compiler and the standard library. It would be impossible to try to make the switch now that the language is widely used. It might be childish for me to choose one language for a project than another over trivial things like semicolons, but for the language itself it's an irreversible decision once the spec gets set in stone.
    • jboy 13y ago
      To me, one of the most interesting design decisions of Rust is that the creators strongly try to avoid inventing new language features. Instead, they attempt to find the best combination of tried-and-true existing features from a variety of other languages. I wonder whether language syntax could be considered such a "feature" -- that is, the Rust creators would consciously prefer to combine existing syntaxes (at this point, mainly C++, Haskell, OCaml and Ruby) than invent their own. An argument could be made that they could just "use Python's syntax", but perhaps a counter-argument would be that Python's syntax would need to be extended so much (for types, pointers, templates, etc.) that the result would effectively be a new invention.
      • lobster_johnson 13y ago
• gnuvince 13y ago
  I think the syntax decision is a good one. Indentation-based structure is nice, however in some cases it can cause some pains: code generation or embedding code in a document are two common examples. As for requiring semi-colons, I don't really mind them; in fact, I'm less annoyed at having to type semi-colons than having to remember rules for auto-insertion or semi-colons.
  • chongli 13y ago
    Haskell solves this problem by allowing both. In any situation where layout/indentation has meaning, braces and semicolons may be substituted.
• jboy 13y ago
  I think it would be an exceedingly interesting project to define a Pythonic syntax for Rust, then implement a Cfront-like frontend to translate Pythonic-Rust to brace-and-semicolon Rust before compiling it. (The Rust language spec is gradually reaching a point where there would presumably not be large, disruptive changes.) You could make it available to the Rust community (and even the broader Rust-interested community on HN and Reddit) and see if it takes off. If the Python-Rust were to become more popular than brace-and-semicolon Rust, the creators may well be persuaded to adopt it. Or at the very least, you'd have a thriving like-minded Python-Rust community. :)
  • steveklabnik 13y ago
    There already is `rustc --pretty`, but it has some bugs and such. I'm sure you could modify it for that purpose.
• pcwalton 13y ago
  The use of semicolons and braces was a decision made in the early days to make C++ programmers feel more at home. There are really good arguments both for and against whitespace-oriented syntax. (I actually prefer whitespace-oriented syntax, although I can see the arguments on the other side!) But we had to pick one and disappoint somebody.
  • lobster_johnson 13y ago
    I wonder how much surveying you guys did? As a sometime C++ dev, I fully recognize the utter inanity and burden of typing semicolons where the compiler should know perfectly my intent, and would rejoice in a language that did away with them. In fact, it's one of the features of Go that I really like. Rust's syntax, on the other hand, feels like a step backwards in some ways. I wrote a bit more here: https://news.ycombinator.com/item?id=5608157 https://news.ycombinator.com/item?id=5608157.
    • dom96 13y ago
      You should checkout the Nimrod programming language which has a syntax similar to Python, i.e. it gets rid of the semicolons and braces.
    • luser001 13y ago
      I personally like semicolons. It's similar in spirit to the period of English. Even languages which didn't traditionally have the period have adopted it in the last couple of centuries. More practically, it seems to remove a class of errors. Semicolons are optional in Javascript and I've seen posts here about subtle errors that can creep in when you change code a little carelessly. And even more practically, it allows you to type "one liners" into things like REPLs even if they aren't one liners. Just my two cents.
      • lobster_johnson 13y ago
        The period is necessary in human languages because we write sentences next to each other and we need some way to separate them. Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course. Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an optional measure if you do want to cram several statements together on the same line. You mention one-liners; a semicolon-free language can support semicolons. Here's a Ruby one-liner: >> b = Box.find(3); t = Thing.new; b.add_thing(t) A class of errors: Well, anecdotally, I have personally never had a single issue with semicolons in JavaScript in all my years developing with it, simply because I always use semicolons. The reason is that JavaScript has a bunch of "semicolon insertion" rules that are not well understood, so dropping the semicolons is a bad idea, as the recent "fiasco" showed, and I just decided very early on not to go that route. As I understand it, JS is a semicolon-enforced language that allows you to drop them at your convenience, whereas Ruby, for example, is a semicolon-free language that allows you to include them at your convenience. I'm not a parser expert, and I won't swear there is a significant difference except in which rules are defined. But I do know that semicolons are categorically not an issue in Ruby. So I would say that this argument is invalid, too, because it presents a flawed language as the ideal. The Rust guys should not need to base their design on JavaScript.
• lobster_johnson 13y ago
  I can accept the braces, but the semicolons were a big letdown for me. We should have learned by now from successful languages that the semicolons is obsolete. If Ruby can do it (and Ruby does it very well with just a few simple rules, even though its lexer admittedly contains parsing logic to deal with the challenge), then Rust can do it. The other disappointing aspect of Rust is the "line noise" problem. Rust has three types of pointers, and needs a line-noise character for each of them. That, combined with the liberal use of underscore-based identifier names, makes it very noisy. (Ruby also uses underscore-based names, but the relative absence of noise characters keeps it clean.) In my opinion any new language project ought to have an overriding aesthetics process. Aesthetics is often belittled (as you say, "childish"), but code readability, over time, becomes more important than almost everything else. I like Rust's design principles, but Go definitely wins the syntax competition for me.
  • pcwalton 13y ago
    > Rust has three types of pointers, and needs a line-noise character for each of them. `~T` and `@T` were felt to be preferable to `std::unique_ptr<T>` and `std::shared_ptr<T>`. You really do type them all the time.
    • lobster_johnson 13y ago
      I understand that. That's not the alternative I want. Go actually gets by with just one type of pointer syntax. Go is what a colleague calls "being stupid simple", which is really its strongest asset at this point. It eschews a lot of complexity by not trying to be clever. The problem with Go's pointers is that no thought has gone into thinking about goroutines as boundaries of data ownership. It's simple to share mutable data between goroutines, and it's impossible to verify (manually or by any kind of analysis) that a program is not a shared-everything pile of spaghetti. This, plus mutable data, makes it impossible to safely implement things like Erlang-style remote task spawning. What I would like in my ideal language is a single pointer type: A pointer into the task heap. However, pointers may only be shared between tasks by copying or by transfering ownership, except for immutable data, which can be shared freely with no overhead other than normal GC/refcounting. With some COW magic you could even make the copying really fast, too. Then all you need is a simple syntax for limited references that cannot be stored, only copied, so that you can actually have functions that work on data efficiently without leaking their pointers anywhere. Maybe I am being naive -- I won't pretend to be a Rust expert. But this model works pretty well for Erlang. I find that while Rust is clever, it falls into the other extreme and becomes too clever; and being too clever is a kind of stupidity. For example, borrowed pointers sound neat on paper, but then you find you have to dick around with declaring pointer lifetimes. That's pretty insane. It results in a kind of syntax that represents everything I hate C++ for. I can understand that it took a while to decide on a syntax for declaring lifetimes. It looks totally weird and arbitrary. (Quotes are for strings, man!) It's also possible that Rust just is not for me. :-)
• ww520 13y ago
  I found the braces and semicolons easy to work with and make reading code much easier. The line continuation (\) in other languages make it ugly. Complaining about braces and semicolon is like complaining about parenthesis in LISP. Learn to appreciate the strength of a language and move beyond its syntax.