3 ms·

Many people seem to be confused by Rust's lack of limitations imposed on you as a programmer. In particular, the fact that so much of what is thought of as a r

Many people seem to be confused by Rust's lack of limitations imposed on you as a programmer. In particular, the fact that so much of what is thought of as a runtime is provided as optional libraries. You can run tasks similar to Goroutines, which are provided as a library. You can use certain types of garbage collection as a library. You have dramatic freedom and accessible choices. The possibilities are incredibly inspiring.

SwellJoe 12y ago
In my tinkering with both Go and Rust, and liking the looks of both, I get vague feelings like Go is to Python as Rust is to Perl. This may be damning praise for some folks, but it makes me lean slightly toward Rust more than Go (slightly). There seems to be almost an anti-library culture in Go (i.e. "use the standard library" is almost a mantra in Go) whereas in Rust, there's more than one way to do it (even this early in its existence). That said, in many ways neither language is like the one I've compared it to, probably in enough ways that it's not a useful comparison for much other than this one metric (the TIMTOWDIness of the language). But, it's how my head is processing these two quite novel (to me) languages; which would make sense, as I've written more code in Python and Perl than probably anything else, so they're the known things I compare these unknown things to.
- thirsteh 12y ago
  You could say that Go is Python and Rust is Haskell, because, well, Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.
  - vezzy-fnord 12y ago
    Could you elaborate on that? Rust has a powerful static type system, HOFs, is expression-based, has an unusually good pattern matching engine for its intended area, assumes immutability by default and uses a notation for function signatures typically associated with FP, but I don't think those are enough to call it a "cleverly disguised Haskell". In fact, it has been my observation that the language has been getting progressively less functional since its early days. Not that I consider this to be bad.
    - thirsteh 12y ago
      Sure -- basically what you said: http://science.raphael.poss.name/rust-for-functional-programmers.html#straightforward-equivalences http://science.raphael.poss.name/rust-for-functional-program... Of course it's not exactly Haskell, but it's arguably closer to FP than it is to C, yet manages to be approachable to imperative programmers. I think this is fantastic.
      - nightski 12y ago
        That would be a really tough argument to make. It goes to great lengths to give control over memory layout and control and lacks a LOT of the features of Haskell's type system. It's a lot more like a prettier D than Haskell. Not only that with every iteration it has been moving farther away from the FP paradigm.
        naasking 12y ago
        I think you mean GHC's type system, since Rust is arguably quite close to Haskell 98 in spirit, ie. algebraic types, lambdas, pattern matching, traits = single parameter type classes.
    - Retra 12y ago
      I think the point is that it seems actively inspired by Haskell -- that the things people like about Haskell are the same things the designers of Rust want in their language.
      - saosebastiao 12y ago
        As far as I can tell, there is some Haskell inspiration in the form of typeclasses (traits in Rust), but almost everything else that resembles FP has a more common denominator in ML. (Even Haskell's type classes have some common lineage with SML Functors)
  - agumonkey 12y ago
    Reminds me of hop and house (haskell based OS) http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299 ~ 2004
  - detrino 12y ago
    > Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers. This comment is very condescending. It makes it seem as if C programmers are ignorant and Haskell programmers are enlightened. Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. These are also qualities not shared by Rust, which may explain why there is less resistance in its uptake by C programmers.
    - thirsteh 12y ago
      Oh, come on. Don't take things so seriously. There are tons of Haskell programmers who don't know C, too, and Rust is just as much of a way for them to reap the benefits of C as it is anything else.
    - naasking 12y ago
      > Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. Don't be so sure! [1] You could simply use Haskell as a metalanguage to generate a C program that does what you need, just like they did with copilot. No Haskell runtime needed. [1] https://github.com/leepike/copilot-discussion https://github.com/leepike/copilot-discussion
  - kyllo 12y ago
    I'd say Rust is more like C and OCaml had a baby.
    - saosebastiao 12y ago
      An amazing compliment, IMO.
tuxychandru 12y ago
Which library provides goroutine like concurrency in rust?
- krenoten 12y ago
  With 1.0, rust no longer has a runtime at all, so official support for libgreen was actually dropped. However, between sync::mpsc, sync::TaskPool and sync::Future you can produce similar results.
  - tuxychandru 12y ago
    All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services). libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.
    - krenoten 12y ago
      Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.
      - tuxychandru 12y ago
        It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.
vegedor 12y ago
>Many people seem to be confused by Rust's lack of limitations imposed That sounds ridiculously like PR-speak. Without the double negative the only information I get is, people are confused by the possibilities, that are however not unlimited - which isn't very surprising for people new to the language.

SwellJoe 12y ago

In my tinkering with both Go and Rust, and liking the looks of both, I get vague feelings like Go is to Python as Rust is to Perl. This may be damning praise for some folks, but it makes me lean slightly toward Rust more than Go (slightly). There seems to be almost an anti-library culture in Go (i.e. "use the standard library" is almost a mantra in Go) whereas in Rust, there's more than one way to do it (even this early in its existence). That said, in many ways neither language is like the one I've compared it to, probably in enough ways that it's not a useful comparison for much other than this one metric (the TIMTOWDIness of the language). But, it's how my head is processing these two quite novel (to me) languages; which would make sense, as I've written more code in Python and Perl than probably anything else, so they're the known things I compare these unknown things to.

thirsteh 12y ago
You could say that Go is Python and Rust is Haskell, because, well, Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.
- vezzy-fnord 12y ago
  Could you elaborate on that? Rust has a powerful static type system, HOFs, is expression-based, has an unusually good pattern matching engine for its intended area, assumes immutability by default and uses a notation for function signatures typically associated with FP, but I don't think those are enough to call it a "cleverly disguised Haskell". In fact, it has been my observation that the language has been getting progressively less functional since its early days. Not that I consider this to be bad.
  - thirsteh 12y ago
    Sure -- basically what you said: http://science.raphael.poss.name/rust-for-functional-programmers.html#straightforward-equivalences http://science.raphael.poss.name/rust-for-functional-program... Of course it's not exactly Haskell, but it's arguably closer to FP than it is to C, yet manages to be approachable to imperative programmers. I think this is fantastic.
    - nightski 12y ago
      That would be a really tough argument to make. It goes to great lengths to give control over memory layout and control and lacks a LOT of the features of Haskell's type system. It's a lot more like a prettier D than Haskell. Not only that with every iteration it has been moving farther away from the FP paradigm.
      - naasking 12y ago
        I think you mean GHC's type system, since Rust is arguably quite close to Haskell 98 in spirit, ie. algebraic types, lambdas, pattern matching, traits = single parameter type classes.
  - Retra 12y ago
    I think the point is that it seems actively inspired by Haskell -- that the things people like about Haskell are the same things the designers of Rust want in their language.
    - saosebastiao 12y ago
      As far as I can tell, there is some Haskell inspiration in the form of typeclasses (traits in Rust), but almost everything else that resembles FP has a more common denominator in ML. (Even Haskell's type classes have some common lineage with SML Functors)
- agumonkey 12y ago
  Reminds me of hop and house (haskell based OS) http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299 ~ 2004
- detrino 12y ago
  > Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers. This comment is very condescending. It makes it seem as if C programmers are ignorant and Haskell programmers are enlightened. Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. These are also qualities not shared by Rust, which may explain why there is less resistance in its uptake by C programmers.
  - thirsteh 12y ago
    Oh, come on. Don't take things so seriously. There are tons of Haskell programmers who don't know C, too, and Rust is just as much of a way for them to reap the benefits of C as it is anything else.
  - naasking 12y ago
    > Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. Don't be so sure! [1] You could simply use Haskell as a metalanguage to generate a C program that does what you need, just like they did with copilot. No Haskell runtime needed. [1] https://github.com/leepike/copilot-discussion https://github.com/leepike/copilot-discussion
- kyllo 12y ago
  I'd say Rust is more like C and OCaml had a baby.
  - saosebastiao 12y ago
    An amazing compliment, IMO.

tuxychandru 12y ago

Which library provides goroutine like concurrency in rust?

krenoten 12y ago
With 1.0, rust no longer has a runtime at all, so official support for libgreen was actually dropped. However, between sync::mpsc, sync::TaskPool and sync::Future you can produce similar results.
- tuxychandru 12y ago
  All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services). libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.
  - krenoten 12y ago
    Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.
    - tuxychandru 12y ago
      It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.

vegedor 12y ago

>Many people seem to be confused by Rust's lack of limitations imposed That sounds ridiculously like PR-speak. Without the double negative the only information I get is, people are confused by the possibilities, that are however not unlimited - which isn't very surprising for people new to the language.