nikomatsakis

Technically, byte-strings (and nested comments) mean the lexer is not regular, but the grammar is still context-free. But anyway, parsing is not typically the bottle-neck these days.

The final draft made an effort to address those concerns -- but also they are completely inapplicable to optimized builds, as kibwen points out. (And if you care how fast your code runs, you really do want optimizations...)

I hadn't actually followed the link in the original post. I see that the claims there were slightly different than what I was thinking of. Nonetheless, I stand by what I wrote above.

In particular, while I of course agree with the author that one can write buggy code in any language, I also have found that following Rust's idioms leads to code that is less buggy. This is not unique to Rust: I've also had similar experiences in Scala and Ocaml. What Rust brings to the table is that it supports zero-cost-abstractions, doesn't require a virtual machine, and guarantees data-race-freedom (a rather useful propery).

I don't know that anyone claimed that a bug similar or analogous to heartbleed couldn't be reproduced in Rust. If they did, that was certainly an overstatement. I think more concretely people claimed that unreachable code yields a warning in Rust, which is absolutely true, but certainly not equivalent to saying something like a heartbleed bug would not happen.

In general, Rust is fairly aggressive about linting for "small" details like unused variables, unreachable code, names that don't conform to expected conventions, unnecessary `mut` annotations, and so forth. I've found that these lints are surprisingly effective at catching bugs.

In particular, the lints about unused variables and unreachable code regularly catch bugs for me. These are invariably simple oversights ("just plain forgot to write the code I meant to write which would have used that variable"), but they would have caused devious problems that would have been quite a pain to track down.

I've also found that detailed use of types is similarly a great way to ensure that bugs like heartbleed are less common. Basically making sure that your types match as precisely as possible the shape of your data -- with no extra cases or weird hacks -- will help steer your code in the right direction. This is a technique you can apply in any language, but good, lightweight support for algebraic data types really makes it easier to do.

See also the discussion thread: http://discuss.rust-lang.org/t/orphan-rules/1322/26

I wouldn't be so quick to give up on GC support yet! "We have a plan!" But I don't think we'll have it in for Rust 1.0. And it's true that, even if we never do get it to work in a satisfactory way, the language works just fine without it.

fwiw, I thought the same when I began work on Rust, but I have since gotten quite used to the shorter keywords. At this point, I can't believe the keywords in other languages are so pointlessly long.

But the truth is that whatever the surface syntax is, one quickly gets used to it. What's more important are the core concepts at work.

I wrote up a quick blog post to spell out some of the examples and show how the design aims for a consistent meaning for the `ret` keyword:

http://smallcultfollowing.com/babysteps/blog/2012/04/06/for-...

You're missing something. The semantics of `ret` are always consistent: it always returns from out the innermost `fn()` declaration (closures written using the sugared notation `{||...}` do not count as fn declarations, but closures written as `fn() { ... }` do). In cases where this is not possible, a static error is generated.