5 ms·

As a Haskell programmer and a casual Rust observer (yet to take the dive), I am constantly impressed with the nice balance Rust seems to have struck between Has

As a Haskell programmer and a casual Rust observer (yet to take the dive), I am constantly impressed with the nice balance Rust seems to have struck between Haskell and C. Currently my #1 and #2 languages are Haskell and C. I will definitely jump on the Rust bandwagon with the 1.0 release -- maybe sooner, we'll see.

bsaul 12y ago
As a "many things except haskell ( yet to take a dive) and pure C" developper, i am also extremely eager to try Rust once the 1.0 is out. One painful point i've seen so far is pointer semantics, but it seems pretty much like the only one, and after having read a slidedeck explaining the reason behind them i'm feeling even more excited.
- tel 12y ago
  What's the pain point of Rust's pointer semantics from the POV of a C programmer? I'm genuinely quite interested—especially given that Rust's pointer semantics is one of their major innovations.
  - mackwic 12y ago
    Having done a (simple, but non-trivial) memcached implementation in Rust, the pointer semantic is terrible right now. The compiler tracks all the use of the values and assign them lifetimes. These lifetimes are tagged from a special form of use (value, mutable value, reference, mutable reference, and some more). The idea of Rust memory-safety is to totally forbid two simultaneous mutable lifetime whatever the code path could be. Whatever the code path could be. Do you begin to realize how strong this assumption is ? Yes, the rust compiler is smart. But sometimes, it's not enough and you have to do the lifetime tracking job by yourself. It's awfully hard (even without recursion). But you know what's even harder ? When all the common code patterns you are aware of for a given task doesn't provide enough warranty for the rust compiler. You know what you want to do. It's indeed very simple (can be an inner swap in some sort of algorithm) but you can't find a way to warranty the compiler that all should be good. Because in its own sort of bizarre logic, it makes sense. Then you're trapped. And you are waiting on #rust@irc.mozilla.org an hint from the bunch of truly marvelous guys who pass their time here. TLDR: Rust can't express 100% what others languages do (ML or C based). And in the portion where it can, you have to do a lot of gymnastic to make it compile. And our Memcached, you'll ask ? Well. After 6 days of work, we finally make it compile, and it worked quite fine. But then we got some mysterious tasking errors when reaching 20 clients and gave up at this point.
    - someone13 12y ago
      Do you have the source released somewhere? I'm interested in Rust but haven't really written anything large - I would find it interesting to see what a large project looks like, especially the kinds of problems that come up (like you mentioned).
      - mackwic 12y ago
        Of course, it's here: https://github.com/yaon/lottery https://github.com/yaon/lottery But even if you are familiar with the patterns we used and can guess the architecture, there will be a lot of unexplained code. I don't think you'll be able to extract a lot of knowledge of it. Anyway, you should look for io_thread.rs (I think it's the most interesting file). Look how the scope are defined (especially the use and abuse of "{}"), the alternation of &self and &mut self and random methods put out of the implementation cause rustc would accept anything when they where inside. You can also look at the mixed use of String and str which introduce a lot of chaos. And, last but not least, bonus points if you succeed to understand the why and the how of the explicits lifetimes we had to put.
        pcwalton 12y ago
        Note that the newest version of master Rust does not require you to write the explicit lifetime in io_thread.rs (I didn't see any others).
      - ww520 12y ago
        Here are two Rust projects I did back at the 0.8 time frame. I tried to make it more read-friendly than clever hacks. Some of the syntax might be outdated since Rust has changed quickly and I didn't want to keep updating it until 1.0 is frozen. A memcached client lib implementing both the binary protocol and text protocol, plus sharding to multiple servers. This is simpler in scope. https://github.com/williamw520/rustymem https://github.com/williamw520/rustymem A gzip implementation and deflate implementation. This is more complicate in scope. https://github.com/williamw520/rustyzip https://github.com/williamw520/rustyzip
sriku 12y ago
I too am getting into Rust and am liking what I'm seeing so far. However, I find its type abstraction facilities limited. For example, the concept of a "monad" is not expressible using the trait system so that a bunch of related types can reuse the abstraction. Instead what we have to do is to declare a ListMonad<T>, OptionMonad<T>, with separate signatures for map/join/whatever. Ideally, something like Monad<M<T>> could be the trait specification. edit: Not Monad<M<T>>, but just Monad<M> with the facility to use M<T> in the body of the trait. I don't have a clear idea of how references, lifetimes, etc. would pan out in this case.
- jmgrosen 12y ago
  What you are describing is essentially higher-kinded types (HKT). It is known that we want this, but it's probably going to happen post-1.0.
  - Bougainville 12y ago
    Shouldn't this happen before 1.0, so that the standard library can be designed to make use of it before it's frozen?
    - dbaupp 12y ago
      The standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. There are precise markers and compiler diagnostics that individual parts of the standard library will use to convey their stability properties (including graceful deprecation warnings).
      - Bougainville 12y ago
        > The standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. That's unfortunate. :( Which version will have a full backwards compatibility guarantee?

bsaul 12y ago

As a "many things except haskell ( yet to take a dive) and pure C" developper, i am also extremely eager to try Rust once the 1.0 is out. One painful point i've seen so far is pointer semantics, but it seems pretty much like the only one, and after having read a slidedeck explaining the reason behind them i'm feeling even more excited.

tel 12y ago
What's the pain point of Rust's pointer semantics from the POV of a C programmer? I'm genuinely quite interested—especially given that Rust's pointer semantics is one of their major innovations.
- mackwic 12y ago
  Having done a (simple, but non-trivial) memcached implementation in Rust, the pointer semantic is terrible right now. The compiler tracks all the use of the values and assign them lifetimes. These lifetimes are tagged from a special form of use (value, mutable value, reference, mutable reference, and some more). The idea of Rust memory-safety is to totally forbid two simultaneous mutable lifetime whatever the code path could be. Whatever the code path could be. Do you begin to realize how strong this assumption is ? Yes, the rust compiler is smart. But sometimes, it's not enough and you have to do the lifetime tracking job by yourself. It's awfully hard (even without recursion). But you know what's even harder ? When all the common code patterns you are aware of for a given task doesn't provide enough warranty for the rust compiler. You know what you want to do. It's indeed very simple (can be an inner swap in some sort of algorithm) but you can't find a way to warranty the compiler that all should be good. Because in its own sort of bizarre logic, it makes sense. Then you're trapped. And you are waiting on #rust@irc.mozilla.org an hint from the bunch of truly marvelous guys who pass their time here. TLDR: Rust can't express 100% what others languages do (ML or C based). And in the portion where it can, you have to do a lot of gymnastic to make it compile. And our Memcached, you'll ask ? Well. After 6 days of work, we finally make it compile, and it worked quite fine. But then we got some mysterious tasking errors when reaching 20 clients and gave up at this point.
  - someone13 12y ago
    Do you have the source released somewhere? I'm interested in Rust but haven't really written anything large - I would find it interesting to see what a large project looks like, especially the kinds of problems that come up (like you mentioned).
    - mackwic 12y ago
      Of course, it's here: https://github.com/yaon/lottery https://github.com/yaon/lottery But even if you are familiar with the patterns we used and can guess the architecture, there will be a lot of unexplained code. I don't think you'll be able to extract a lot of knowledge of it. Anyway, you should look for io_thread.rs (I think it's the most interesting file). Look how the scope are defined (especially the use and abuse of "{}"), the alternation of &self and &mut self and random methods put out of the implementation cause rustc would accept anything when they where inside. You can also look at the mixed use of String and str which introduce a lot of chaos. And, last but not least, bonus points if you succeed to understand the why and the how of the explicits lifetimes we had to put.
      - pcwalton 12y ago
        Note that the newest version of master Rust does not require you to write the explicit lifetime in io_thread.rs (I didn't see any others).
    - ww520 12y ago
      Here are two Rust projects I did back at the 0.8 time frame. I tried to make it more read-friendly than clever hacks. Some of the syntax might be outdated since Rust has changed quickly and I didn't want to keep updating it until 1.0 is frozen. A memcached client lib implementing both the binary protocol and text protocol, plus sharding to multiple servers. This is simpler in scope. https://github.com/williamw520/rustymem https://github.com/williamw520/rustymem A gzip implementation and deflate implementation. This is more complicate in scope. https://github.com/williamw520/rustyzip https://github.com/williamw520/rustyzip

sriku 12y ago

I too am getting into Rust and am liking what I'm seeing so far. However, I find its type abstraction facilities limited. For example, the concept of a "monad" is not expressible using the trait system so that a bunch of related types can reuse the abstraction. Instead what we have to do is to declare a ListMonad<T>, OptionMonad<T>, with separate signatures for map/join/whatever. Ideally, something like Monad<M<T>> could be the trait specification. edit: Not Monad<M<T>>, but just Monad<M> with the facility to use M<T> in the body of the trait. I don't have a clear idea of how references, lifetimes, etc. would pan out in this case.

jmgrosen 12y ago
What you are describing is essentially higher-kinded types (HKT). It is known that we want this, but it's probably going to happen post-1.0.
- Bougainville 12y ago
  Shouldn't this happen before 1.0, so that the standard library can be designed to make use of it before it's frozen?
  - dbaupp 12y ago
    The standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. There are precise markers and compiler diagnostics that individual parts of the standard library will use to convey their stability properties (including graceful deprecation warnings).
    - Bougainville 12y ago
      > The standard library is not being frozen as a whole at 1.0, we are only providing strong backwards compatibility guarantees about the language itself. That's unfortunate. :( Which version will have a full backwards compatibility guarantee?