[rust-dev] First thoughts on Rust

Brian Anderson banderson at mozilla.com
Sun Jan 22 22:18:58 PST 2012


----- Original Message -----
> From: "Masklinn" <masklinn at masklinn.net>
> To: rust-dev at mozilla.org
> Sent: Sunday, January 22, 2012 3:11:41 AM
> Subject: [rust-dev] First thoughts on Rust
> 
> I guess this would be the least-bad mailing list for it
> considering the other one is -commits.
> 
> With Rust 0.1, I finally decided to actually test Rust (kudos for
> a perfect compilation under OSX, by the way, no issue whatsoever
> to report), and have thus encountered interrogations, dislikes,
> or issues. And am thus reporting them here. Warning: I only spent
> about half an hour or an hour with rust.

Thanks for the thoughtful comments!

> I'm aware some of them might have been discussed to death
> beforehand and can have rationales, a simple link to these
> discussions/rationales should be sufficient of course.
> 
> Interrogations:
> ---------------
> 
> * Are there plans for a CLI? Maybe not a full-blown REPL, but a
>   basic execution console which would let users try out snippets
>   without having to create and compile files

No solid plans, but I'm sure everyone agrees it would be sweet.

> 
> * In the use-crate specification, are attributes arbitrary and
>   always exactly matched? My concerns are mostly with the `vers`
>   attribute of the examples, as strict equality is
>   sometimes (often) not what is wanted, with richer/more flexible
>   specifications being useful (as well as more than one spec)
>   e.g. vers >= 1.5, vers < 2
>   - Linked to this, if some attributes have special status does
>     Rust enforce a specific style for version numbers
>     e.g. semver?

Besides 'name' and 'vers' the attributes are arbitrary and by convention. Right now they are exactly matched, but you are right that's often not what one wants. Versioning is very incomplete at the moment. I think currently rustc doesn't enforce anything except that 'name' and 'vers' are strings (and not some other literal type).

> * Are python-style chained comparison operators (e.g. `3 < a < 5`
>   being true iif a is in ]3.0, 5.0[) planned? They don't seem to
>   be possible right now, the example above fails to typecheck.

I have never heard this discussed.

> * Do the rustc &al libraries provide services to third-parties
>   which would allow for easily building e.g. analysis or
>   transformation tools (such as refactoring utilities)? Would
>   they give AST-level access to third-party tools such as the
>   Rust emacs mode or an IDE? I did not see any hint to
>   documentation of these libraries and their services.

Absolutely. rustc is just a driver that links to librustc, which is also used by cargo, rustdoc and the fuzzer. There's no documentation because nobody has put effort into designing a nice API and it's not a major focus right now. The intent is definitely that the compiler be exposed as one or more libraries for tools to use.

> Issues:
> -------
> 
> * The first one is the apparent (community) usage of "blocks" for
>   Rust's boxed closures[0]. My issue with this is that languages
>   where
>   blocks are first-class objects (Smalltalk, Ruby) default to
>   non-local returns from these blocks. Rust does not — as far as I
>   can
>   tell — have — let alone use — non-local returns.
> 
>   Using "block" for boxed closures does everybody a disservice as it
>   makes transition much harder and *will* disappoint people used to
>   actual smalltalk-type blocks. The tutorial does not have this
>   issue,
>   which is good, but the community should be careful. Talking about
>   lambdas or sugared lambdas would probably be a good idea (unless
>   Rust is modified to handle and default to non-local returns from
>   stack closures)

Non-local returns have been discussed frequently - there's a lot of demand but so far we haven't come up with a way to do it that anybody is that thrilled about. I think the term 'block' is being phased out - the keyword is definitely going away. Possibly they will be referred to as 'stack closures'.

> * The second issue is both trivial and extremely serious: after
>   having written a few trivial pieces of code (can't call them
>   programs), it feels like Rust's handling of semicolons combines
>   the simplicity of Erlang's with the determinism of
>   Javascript's.

Others share your opinion, and it is admittedly a stumbling block.

>   I think the core issue is that Rust uses semicolons as expression
>   separators where most if not all other braceful languages use them
>   as expression terminators. I know the rules are simple to express,
>   but Erlang demonstrated it would *never* feel right to people in
>   the
>   current state of the language. Erlang also has the issue of three
>   different separators, but Rust has the additional issue that a
>   semicolon becomes the difference between returning a value and
>   returning unit. That's not right.
> 
>   I see three possible ways to fix this:
> 
>   - Don't change Rust's semantics, but change Rust's "blessed" style,
>     by prefixing expressions with semicolons (instead of
>     post-fixing). This is a common style for e.g. RelaxNG-Compact
>     schemas and it looks "correct" for separators
> 
>   - Make semicolons into expression terminators, as in the majority
>   of
>     C-style languages

To do this I think the type checker would have to infer your intentions about what should be done with the last statement of the block. Some rules have been proposed in the past to make this work, but I don't remember the details.

> 
>   - Add haskell-like layout rules making semicolons redundant in
>   99.9%
>     of cases, and necessary only when putting multiple expressions on
>     a line or when generating rust code mechanically. This would fix
>     the issue by making semicolons generally unnecessary and thus not
>     a source of error
>
> * Strings. I believe Rust's current state of conflating byte
> sequences
>   and human-text strings to be as big a mistake as it was in Python.

I don't have any knowledge about this subject. It's a terribly difficult thing to get right, and I do worry about the built in string type and accompanying library.

> * I find strange that Rust has kept the ternary operator even though
>   its conditionals are expressions of their own.

At one point there was some desire to be able to write if-else expressions more compactly and it was trivial to add to the language. I tend to agree that it's not necessary.

> * Finally, I could not find any good information on the result of
> loop
>   expressions, from my tests it seems to always be `()` is that
>   correct? If so, why `()` rather than the last-evaluated result of
>   the iteration? In case no iteration at all is performed?

You are correct that loop expressions always have type (). The reason you suggest sounds convincing to me.

> Thank you for reading until this point, looking forward to any reply
> and have a nice day.
> 
> [0]
> https://mail.mozilla.org/pipermail/rust-dev/2012-January/001168.html
> [1] http://www.unicode.org/reports/tr36/#UTF-8_Exploit
> [2]
> https://mail.mozilla.org/pipermail/rust-dev/2012-January/001196.html
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
> 


More information about the Rust-dev mailing list