Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A taste of Rust

lwn.net

Post reply on HN
Print view View original

61–70 of 93 posts

Re: A taste of Rust

#61

Post by kibwen »

stesch wrote: post #51
lobster_johnson wrote: post #40

Earlier quoted context omitted.

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 t…

The characters for the different pointer types remind me a little bit of the Hungarian notation. And I thought this is a bad idea.

It's not Hungarian notation, the sigils are part of the type. Here's how you'd say the same thing in Rust and C++:

  Rust: ~T
  C++: unique_ptr

Re: A taste of Rust

#62

Post by dscrd »

coldtea wrote: post #21
zepolud wrote: post #10

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 is a regrettable but nonetheless well justified decision. But why didn't they include a standard indentation style in the language specification itself and get rid of the cruft? They have one for Servo anyway, which is the raison d'etre of the whole language,…

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

No, it's actually the opposite of childish: being able to digest new things is exactly what children do and exactly what adults do less.

Re: A taste of Rust

#63

Post by luser001 »

lobster_johnson wrote: post #42
pcwalton wrote: post #37

Earlier quoted context omitted.

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.

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

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.

Re: A taste of Rust

#64

Post by pcwalton »

Locke1689 wrote: post #49

In contrast to this, array (or, as Rust calls them, "vector") references do not require the compiler to know that the index is in range before that index is dereferenced. It would presumably be possible to use the type system to ensure that indexes are in range in many cases, and to require explicit tests for cases where the type system cannot be sure — similar to the approach taken for pointers. Thus, while it is im…

Right.

Re: A taste of Rust

#65

Post by pcwalton »

lobster_johnson wrote: post #40
zepolud wrote: post #10

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 is a regrettable but nonetheless well justified decision. But why didn't they include a standard indentation style in the language specification itself and get rid of the cruft? They have one for Servo anyway, which is the raison d'etre of the whole language,…

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 t…

> 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` and `std::shared_ptr`. You really do type them all the time.

Re: A taste of Rust

#66

Post by lobster_johnson »

luser001 wrote: post #63
lobster_johnson wrote: post #42

Earlier quoted context omitted.

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

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 allow…

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.

Re: A taste of Rust

#67

Post by lobster_johnson »

pcwalton wrote: post #65
lobster_johnson wrote: post #40

Earlier quoted context omitted.

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 t…

> 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 ` and `std::shared_ptr `. You really do type them all the time.

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

Re: A taste of Rust

#68

Post by Dewie »

lobster_johnson wrote: post #66
luser001 wrote: post #63

Earlier quoted context omitted.

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 allow…

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 op…

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this:

if (something()); { somethingOther(); }

The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.

Re: A taste of Rust

#69

Post by klibertp »

lobster_johnson wrote: post #41
jboy wrote: post #31

Earlier quoted context omitted.

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…

That logic sounds fishy to me. After all, they took C++'s semicolon syntax over Haskell, OCaml and Ruby's semicolon-free syntax, so there must have been a reason for picking one over the others. So the issue is not about inventing syntax, it's about choosing one (existing) syntax over another. pcwalton says it was to attract C++ devs, which is interesting considering that Go was also designed to attract C++ devs and…

Since when OCaml is semicolon-free? It not only has semicolons, single semicolon (;) means something different than double semicolon (;;). The former is used as an expression separator, like comma in Erlang, and the latter denotes the end of a top-level declaration, like period in Erlang. That's a pain while refactoring, but I can live with it. Anyway, that's just a style, nothing more, you can learn to love it or you can write a "transpiler", it's really a non-issue.

Re: A taste of Rust

#70

Post by ufo »

Dewie wrote: post #68
lobster_johnson wrote: post #66

Earlier quoted context omitted.

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 op…

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this: if (something()); { somethingOther(); } The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.

Being able to write if and while loops with am empty body is due to braces being optional if you only have one statement and due to the empty statement being a legal statement (doing so keepsthings simpler).

As for the second {}, its to allow you to create inner scopes where you can declare variables with a more restricted scope without needing to do something silly like "if(true)".

Empty block statements are OK sometimes with while and for loops when the real action that matters is in the condition:

    while(!trySomething()){} //empty body for the loop
And since these language
Post reply on HN