5 ms·

This Week in Rust

70 points by cmrx64 13y ago

noelwelsh 13y ago
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?
- Ygg2 13y ago
  As Rust ML lurker - there was some talk about using macros to fill in for this pain point, if I recall correctly. From what I've gathered do is dead and gone.
  - lucian1900 13y ago
    For anyone not familiar with it, the `do` that was removed provided sugar for calling HOFs similar to Ruby blocks. Monadic do could be added in the future, backwards compatibly.
- dbaupp 13y ago
  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 13y ago
    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 13y ago
      > 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 13y ago
        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 13y ago
        It probably should be reserved.
    - dbaupp 13y ago
      They need to take balanced braces/parens/brackets (i.e. only escaped if they are possibly unbalanced), so that Rust source can still be parsed without having to run the macro expander concurrently. And, it looks like do is no longer a keyword at all, I must've missed that part of the do-removal patch! So it is possible to call that macro do.
- pcwalton 13y ago
  "if_ok!" is designed to handle this. It's basically the equivalent of monadic do, but works better with the control flow structures of Rust.
  - bcj 13y ago
    Is there a location in the docs that lists and describes the built-in macros in Rust? They don't appear to be findable using the stdlib search, and the Macros tutorial doesn't seem to talk about built-ins. Also, this post forced me to read the docs a bit more thoroughly and realize that I haven't been distinguishing between Option and Result. Thanks
tomp 13y ago
> 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...
- octo_t 13y ago
  Pursuing != is. Its a language in the stages of infancy and under active development, of course there are bugs. Its not even at version 1.0 yet!
- dbaupp 13y ago
  A lot of the issues included in that count are pull requests (including ones adding awesome new features, not just fixing bugs), and we get a reasonable number of duplicate filings (which doesn't particularly matter: it gives us more test code for the suite).
- banachtarski 13y ago
  So would you be more confident in repositories that closed 0 issues? I can point you to plenty of those.
- coldtea 13y ago
  >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 13y ago
    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.
stcredzero 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
sehugg 13y ago
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?

70 points by cmrx64 13y ago

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?

Ygg2 13y ago
As Rust ML lurker - there was some talk about using macros to fill in for this pain point, if I recall correctly. From what I've gathered do is dead and gone.
- lucian1900 13y ago
  For anyone not familiar with it, the `do` that was removed provided sugar for calling HOFs similar to Ruby blocks. Monadic do could be added in the future, backwards compatibly.
dbaupp 13y ago
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 13y ago
  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 13y ago
    > 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 13y ago
      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 13y ago
        It probably should be reserved.
  - dbaupp 13y ago
    They need to take balanced braces/parens/brackets (i.e. only escaped if they are possibly unbalanced), so that Rust source can still be parsed without having to run the macro expander concurrently. And, it looks like do is no longer a keyword at all, I must've missed that part of the do-removal patch! So it is possible to call that macro do.
pcwalton 13y ago
"if_ok!" is designed to handle this. It's basically the equivalent of monadic do, but works better with the control flow structures of Rust.
- bcj 13y ago
  Is there a location in the docs that lists and describes the built-in macros in Rust? They don't appear to be findable using the stdlib search, and the Macros tutorial doesn't seem to talk about built-ins. Also, this post forced me to read the docs a bit more thoroughly and realize that I haven't been distinguishing between Option and Result. Thanks

tomp 13y ago

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

octo_t 13y ago
Pursuing != is. Its a language in the stages of infancy and under active development, of course there are bugs. Its not even at version 1.0 yet!
dbaupp 13y ago
A lot of the issues included in that count are pull requests (including ones adding awesome new features, not just fixing bugs), and we get a reasonable number of duplicate filings (which doesn't particularly matter: it gives us more test code for the suite).
banachtarski 13y ago
So would you be more confident in repositories that closed 0 issues? I can point you to plenty of those.
coldtea 13y ago
>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 13y ago
  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.

stcredzero 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.

sehugg 13y ago

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?