

This Week in Rust - cmrx64
http://cmr.github.io/blog/2014/02/09/this-week-in-rust/

======
stcredzero
Someone needs to write a "History of Programming Language Design Mistakes."
(Not saying Rust is one of these.)

While working for a Smalltalk vendor, I got to see that the various Smalltalk
implementations all made the same mistakes. (Visualworks, ObjectStudio,
Digitalk) Then later on, I've seen eerie reminders of those things I saw in
other environments/languages.

This is a highly complex subject, not only spanning a great deal of technical
material, but also interactions within communities of many programmers,
decision makers, and others.

I think such a book would be highly valuable to the programming field. (Or, as
Alan Kay says, "not quite a field.")

~~~
chubot
Here's one that's been on my mind that I haven't seen people talk about:
making O(1) and O(n) operations look the same.

Example in Python:

    
    
       d = { ... }
       for ...
         if 'key' in d:
           func()
    
       L = [ ... ]
       for ...
         if 'key' in L:
           func()
    

Python is my favorite language, and I teach Python classes, but the number of
both beginner and production programs I've seen with quadratic blowups because
of this issue is crazy.

I think a lot of the problem is the subtle syntax. People with a solid CS
background find this distinction fairly natural, but most Python programmers
apparently don't.

I guess the alternative syntax would be L.find(), which sort of emphasize the
linear search. It seems WAY more elegant to have the polymorphic "in", but the
number of mistakes is too high.

Actually now that I think about it, this was question #0 on the stripe CTF3.
So I guess the same thing happens often enough in Ruby for them to use it as a
question.

~~~
j_baker
I see this as ultimately being a much better from an optimization standpoint.
Now I can change L to a set or a linked list if I find that more efficient
without having to change it _everywhere_. Language features are no substitute
for algorithm and data structure knowledge, which your students can likely be
forgiven for not knowing about.

~~~
chubot
I don't buy it. Physically editing text is never the problem when changing a
data structure like this. The work is ensuring your program is still correct
and performs better.

~~~
dragonwriter
Ensuring code is "still correct and performs better" is made easier if only
the data structure used has to change to get "performs better", and the "still
correct" comes free with it because the operation that performs the same
function is the same operation regardless of the efficiency of the algorithm.

------
noelwelsh
As some of the Rust developers hang around here, a question:

Result is the Either monad in Scala / Haskell? So IO functions return either a
success wrapping a value, or a failure? This is great -- I'm a big fan of this
style of error handling. However it seems that Rust doesn't have syntax for
monads -- the equivalent of Haskell's do and Scala's for. This makes monads a
bit of a PITA. Is there a plan to address this?

~~~
dbaupp
People keep wanting monadic syntax (I'm one of them), but I believe the
general suggestion is to do it via macros/syntax extensions. E.g. write
something that desugars

    
    
       do! {
           bind x = foo();
           let bar = baz(10);
           ret x + bar
       }
    

into the equivalent of Haskell's

    
    
       do 
        x <- foo
        let bar = baz 10
        return $ x + bar
    

Rust currently lacks higher-kinded types, so it would be hard to write
functions that are generic over monads but the above would at least give some
local reprieve.

Also, note the `if_ok!` macro alluded to in the point about IO errors is
giving the shortcircuiting behaviour of the Either monad (specific to Either,
though).

(NB. the macro probably can't be called `do` just yet, but we may remove that
as a keyword. Maybe.)

~~~
Ygg2
Wait, how don't macro need to take escaped sigils?

Like range! takes range!('[' 0 , Inf ')' )?

Is 'do' still a keyword? I remember it being removed, pretty much everywhere.
I just assumed it was thrown away.

~~~
lucian1900
> Wait, how don't macro need to take escaped sigils?

These are proper (hygienic) syntax macros, much like Scheme's syntax-rules.
C's "macros" only work at the token level.

> Is 'do' still a keyword?

I believe it is still a reserved keyword, but not used anymore.

~~~
dbaupp
It appears to not be a reserved word at all:

    
    
      $ echo 'fn main() { let do = 1; }' | rustc -
    

runs with just an unused variable warning (if it were reserved it would fail
with "error: `do` is a reserved keyword").

~~~
brson
It probably should be reserved.

------
sehugg
I noticed that rustpkg has been removed, leaving Rust essentially without an
official package manager for the time being. Can't say I'm heartbroken, but
what's the plan?

------
tomp
> Rust is a systems language pursuing the trifecta: _safe_ , concurrent, and
> fast.

> It was also discovered that we closed the second largest number of issues of
> any repository on GitHub!

Doesn't make me very confident...

~~~
coldtea
> _Doesn 't make me very confident..._

This makes no sense at all. For one, it's a language under heavy development.
Obviously most of these issues where things not implemented already, library
ftuff missing, temporary implementations that had to be changed to the new
one, small and bigger regressions due to syntax and library changes etc etc.

Second, you'd rather those issues remained open? Or that magically some
rainbow unicorns perhaps would have prevented the language from having any
issues in the first place?

What matters is that the number of issues drops low enough, as the language
tries to reach version 1.0. And what the announce here is very well aligned
with that goal.

~~~
Pacabel
There's no need to be snide.

I think he may just be surprised that those bugs still occurred, given how the
Rust toolchain is itself implemented in Rust, by the designers of Rust, and
how Rust is supposedly designed in a way that prevents bugs to a larger extent
than other languages do.

It's understandable where he's coming from. If those who know Rust the best
are still subject to bugs in their Rust code, it's perfectly valid and
reasonable to wonder if the rest of us really be any better off than we are
with Java, or C#, or Python, or whatever language(s) we're currently using.

~~~
coldtea
> _I think he may just be surprised that those bugs still occurred, given how
> the Rust toolchain is itself implemented in Rust, by the designers of Rust,
> and how Rust is supposedly designed in a way that prevents bugs to a larger
> extent than other languages do._

Well, then what he probably doesn't understand is that those bugs are not in
their majority memory bugs or sound-ness bugs or bugs in the things Rust is
supposed to protect you from.

Most are issues related to half or mis-implemented features, syntax that
changed and libs that need to change in accordance, etc. If I have:

random() { return 6;}

as a stub, I could post an issue to remind me to implement a actual random
number generator later. Doesn't mean the language has some inherent problem
itself.

