5 ms·

I evaluated Rust a couple of months ago and had to reject it because it's pointy nature makes it difficult to write high order functions.

• tinco 13y ago
  What language did you choose in the end?
  • Touche 13y ago
    Lua
    • andrewflnr 13y ago
      What kind of project was it that both Lua and Rust were in the running? Those are pretty much on opposite ends of spectrum, at least the spectrum of imperative languages with functional parts.
      • fit2rule 13y ago
        Don't forget that you can embed Lua in a collection of C libraries, and thus: do system programming with it. ;)
• steveklabnik 13y ago
  What made it so hard? I'd be interested in hearing more.
  • Touche 13y ago
    Unfortunately I don't still have the code I was writing to tell you exactly, but the main issue is that you can't write generic functions because some times your usage will need to pass in a reference, some times not. The map and filter functions are examples of this. My hello world for evaluating a language is this: write a program that sums its arguments. It's arguments might be numbers or strings so you have to filter and cast. It's a simple program but I find it a good indicator of how elegant (in terms of what I consider elegant of course) a language is to use on a daily basis. Lisps obviously do best in this type of test but Haskell also does very well despite it's type system. So the issue isn't types, it's pointers.
    • kibwen 13y ago
      Ruster here, and this is also something that concerns me (I too have run afoul of the map vs filter issue that you mention). We'll need to carefully consider our composable higher-order-function APIs before 1.0.
      • lucian1900 13y ago
        I think an approach like Clojure's reducers might work, since it's possible to compose several higher-order operations and end up with no extra allocations or loops.
    • pcwalton 13y ago
      > Unfortunately I don't still have the code I was writing to tell you exactly, but the main issue is that you can't write generic functions because some times your usage will need to pass in a reference, some times not. The map and filter functions are examples of this. Usually you pass references, because that's the most generic option. I wouldn't say "you can't write generic functions", but you sometimes have to add wrappers that convert between levels of indirection. > My hello world for evaluating a language is this: write a program that sums its arguments. It's arguments might be numbers or strings so you have to filter and cast. It's a simple program but I find it a good indicator of how elegant (in terms of what I consider elegant of course) a language is to use on a daily basis. Lisps obviously do best in this type of test but Haskell also does very well despite it's type system. So the issue isn't types, it's pointers. Certainly a language can be easier to use and you can write more elegant-looking code if most everything is a reference. No argument there. It basically sounds like you weren't using the low-level features of Rust, which are important for our use cases but not important for everyone's. So Rust might well not be for you. That's totally fine, as I don't intend for Rust to be the one language to rule them all.
      • hrjet 13y ago
        "It basically sounds like you weren't using the low-level features of Rust, which are important for our use cases but not important for everyone's." But even in a system level program, how often do you need low level features of the language. I think the answer is "very seldomly", and hence, these low level features should be tucked in behind the higher level abstractions. They should be available only when required.