9 ms·

Man Rust is super hard already! I mean people told me it would be harder to think functionally but after clojure, i think lisps are super easy. But i feel Rust

Man Rust is super hard already! I mean people told me it would be harder to think functionally but after clojure, i think lisps are super easy. But i feel Rust is way harder than anything. Infact i feel Haskell is comparatively easier than Rust. So i am not sure why one wants to use it for web. I think Rust has a place and that is to replace C++ for system software, possibly even C for writing Kernels because why not? But definitely not for web. Go is probably the right choice for that sort of performance scenario in the backend. But for frontend neither Go or Rust are good simply because of the huge size of the runtimes. Clojure-script comparatively has a smaller runtime than either Go or Rust runtimes compiled to JS.

haskellandchill 9y ago
Haskell has more concepts than Rust (like higher kinder types) and should get linear types soon. Rust seems like Go with some Java and the great borrow checking system.
- pcwalton 9y ago
  Associated types put Rust beyond Java and far beyond Go in terms of type system features, even without counting anything lifetime-related.
  - haskellandchill 9y ago
    Interesting, didn't know it had something like type families. Thanks!
- moomin 9y ago
  With the best will in the world, linear types are still going to take some serious work. Look at the guy doing a linear type streaming library. And that's just at the language level. You then need pervasive library support. And then you need more GHC work on optimisation, work out how you interoperate with levity polymorphism and so on and so on. And _after_ all this work is done, I seriously doubt you'll be able to control memory usage as well as Rust does now. I love Haskell to bits, but there's no way it's going to beat Rust at what Rust's good at for a long time to come.
  - pjmlp 9y ago
    > And _after_ all this work is done, I seriously doubt you'll be able to control memory usage as well as Rust does now. Which might be totally irrelevant in most use cases, if it is within the desired application bounds. I have replaced more C++ systems with Java and .NET solutions than the other way around.
    - moomin 9y ago
      Well yes, but that's true right now as well. There's definitely things that Haskell's better than Rust at, but OP was arguing that it was going to be better in _all_ cases. Instead, the choice in five years time is going to be pretty similar to what it is now.
      - wtetzner 9y ago
        > but OP was arguing that it was going to be better in _all_ cases. I wasn't clear to me if haskellandchill was claiming that Haskell will be better, or if Haskell is more complicated. I assumed they meant it's more complicated than Rust, but now I'm not sure.
        moomin 9y ago
        Ironically, I think linear types are really cool. But I also think it's going to be years before benefits are seen in average programs.
        haskellandchill 9y ago
        I meant more complicated.
- lmm 9y ago
  Higher kinded types don't seem like much of an extra concept. If anything they're a simplification: type parameters can be any type, rather than only being unparameterized types.
steveklabnik 9y ago
> But for frontend neither Go or Rust are good simply because of the huge size of the runtimes. Rust has a comparable amount of runtime as C, here it is: https://github.com/rust-lang/rust/blob/master/src/libstd/rt.rs https://github.com/rust-lang/rust/blob/master/src/libstd/rt.... wasm/asmjs does bring in some stuff, because it's mostly in a "it works" state than a "this is as good as it gets" state; our initial implementations didn't even do much optimization at all. Last I checked (last November), an example TodoMVC was to ~650K total, and given that the smallest known Rust binary is 151 bytes, I'd imagine that only gets smaller into the future. https://cryze.github.io/advent-of-code-2016/ https://cryze.github.io/advent-of-code-2016/ has a bunch of Advent of Code programs in Rust, compiled this way; Day 1 is weighing in at 300kb, it looks like. asmjs is also much larger than wasm, day 3 is showing 1.4 MB for asm, but 69kb for wasm.
EugeneOZ 9y ago
No, Rust is simple enough, just few first steps are difficult.
- deleted 9y ago
  [deleted]
pcwalton 9y ago
I'm using Rust/Rocket for Web apps and I'm as productive with that stack as I would be with, say, Go or Python/Flask. I'm more productive with Rust than I would be in Java. Programmers generally write the same amount of code (measured in LOC) per day regardless of the language, and Rust is pretty succinct. That said, I suspect if you want the absolute fastest development time, Rails and full-stack frameworks like it are still king. In my case I'm writing a Web app to expose the functionality of a library that's written in Rust, and Rocket was a natural choice for that—it would make little sense to use some other language and go over the FFI. On the client side, I've found that TypeScript 2.x in strict mode goes nicely with Rust on the server, as both Rust and TS 2.x have comparably feature-rich and expressive type systems (generics, tuples, discriminated unions, a distinct null/option type, etc.)
- yen223 9y ago
  To be fair, you might be a little bit biased ;)
- dgsb 9y ago
  What makes you think software developers write the same average amount of lines of code per day ? It seems to me the higher level the language is, higher is the average number of loc per day. IHMO Debugging has an huge impact on this average and lower level languages are harder to debug.
  - pcwalton 9y ago
    I have not found Rust any harder to debug than, say, Python. LLDB works fine.
    - dgsb 9y ago
      I have no experience with rust so I can not elaborate on that, but I find harder to debug a multi-threaded C++ application where race condition and memory corruption is possible than a python one. That difficulty has an impact on average daily productivity on LOC.
mathw 9y ago
I disagree. I think Rust is pretty easy once you've spent a bit of time learning about lifetimes. It should be substantially less surprising when it's got non-lexical lifetimes, though. Rust seems to me eminently suited to write high-performance web applications.
- pankajdoharey 9y ago
  Well anyone is free to think anything, the Rust compiler is by nature very conservative and tries to take an approach where it wants to you put a lot of information so that it is easier for it compile programs and infer right context. In the process it demands a lot from you compared to Go. Being a C fan i would say C is way easier than Rust, but look where C has lead us, huge amount of headache due to tons of unspecified behavior of C which all compiler makers have diligently copied from each other. So i totally get it Rust is great for these scenarios absolutely, write OS Kernel, Databases, Browsers what have you... But it is really not meant for the web, trying to use Rust for web is retrofitting at best.
- naasking 9y ago
  Let's be serious, Rust will never be as easy to use as a language with GC. It will perform better on many metrics, but you have to pay that cost.
  - sqeaky 9y ago
    Unless you care about resources other than memory. GC doesn't help to make sure mutexes don't deadlock and files are closed. As far as I know there is no general purpose algorithm for those.
    - naasking 9y ago
      Even still, you can opt-in to those features in a GC language when you need it, but the contrary is not the case in Rust at the moment.
      - 9y ago
legulere 9y ago
Rust is pretty much runtime-less. There's some unwinding stuff you could see as a runtime. You can simply replace it with a compiler flag. There is a standard library which you might mean, but you can opt out of that as well.

haskellandchill 9y ago

Haskell has more concepts than Rust (like higher kinder types) and should get linear types soon. Rust seems like Go with some Java and the great borrow checking system.

pcwalton 9y ago
Associated types put Rust beyond Java and far beyond Go in terms of type system features, even without counting anything lifetime-related.
- haskellandchill 9y ago
  Interesting, didn't know it had something like type families. Thanks!
moomin 9y ago
With the best will in the world, linear types are still going to take some serious work. Look at the guy doing a linear type streaming library. And that's just at the language level. You then need pervasive library support. And then you need more GHC work on optimisation, work out how you interoperate with levity polymorphism and so on and so on. And _after_ all this work is done, I seriously doubt you'll be able to control memory usage as well as Rust does now. I love Haskell to bits, but there's no way it's going to beat Rust at what Rust's good at for a long time to come.
- pjmlp 9y ago
  > And _after_ all this work is done, I seriously doubt you'll be able to control memory usage as well as Rust does now. Which might be totally irrelevant in most use cases, if it is within the desired application bounds. I have replaced more C++ systems with Java and .NET solutions than the other way around.
  - moomin 9y ago
    Well yes, but that's true right now as well. There's definitely things that Haskell's better than Rust at, but OP was arguing that it was going to be better in _all_ cases. Instead, the choice in five years time is going to be pretty similar to what it is now.
    - wtetzner 9y ago
      > but OP was arguing that it was going to be better in _all_ cases. I wasn't clear to me if haskellandchill was claiming that Haskell will be better, or if Haskell is more complicated. I assumed they meant it's more complicated than Rust, but now I'm not sure.
      - moomin 9y ago
        Ironically, I think linear types are really cool. But I also think it's going to be years before benefits are seen in average programs.
      - haskellandchill 9y ago
        I meant more complicated.
lmm 9y ago
Higher kinded types don't seem like much of an extra concept. If anything they're a simplification: type parameters can be any type, rather than only being unparameterized types.

steveklabnik 9y ago

> But for frontend neither Go or Rust are good simply because of the huge size of the runtimes. Rust has a comparable amount of runtime as C, here it is: https://github.com/rust-lang/rust/blob/master/src/libstd/rt.rs https://github.com/rust-lang/rust/blob/master/src/libstd/rt.... wasm/asmjs does bring in some stuff, because it's mostly in a "it works" state than a "this is as good as it gets" state; our initial implementations didn't even do much optimization at all. Last I checked (last November), an example TodoMVC was to ~650K total, and given that the smallest known Rust binary is 151 bytes, I'd imagine that only gets smaller into the future. https://cryze.github.io/advent-of-code-2016/ https://cryze.github.io/advent-of-code-2016/ has a bunch of Advent of Code programs in Rust, compiled this way; Day 1 is weighing in at 300kb, it looks like. asmjs is also much larger than wasm, day 3 is showing 1.4 MB for asm, but 69kb for wasm.

EugeneOZ 9y ago

No, Rust is simple enough, just few first steps are difficult.

deleted 9y ago
[deleted]

pcwalton 9y ago

I'm using Rust/Rocket for Web apps and I'm as productive with that stack as I would be with, say, Go or Python/Flask. I'm more productive with Rust than I would be in Java. Programmers generally write the same amount of code (measured in LOC) per day regardless of the language, and Rust is pretty succinct. That said, I suspect if you want the absolute fastest development time, Rails and full-stack frameworks like it are still king. In my case I'm writing a Web app to expose the functionality of a library that's written in Rust, and Rocket was a natural choice for that—it would make little sense to use some other language and go over the FFI. On the client side, I've found that TypeScript 2.x in strict mode goes nicely with Rust on the server, as both Rust and TS 2.x have comparably feature-rich and expressive type systems (generics, tuples, discriminated unions, a distinct null/option type, etc.)

yen223 9y ago
To be fair, you might be a little bit biased ;)
dgsb 9y ago
What makes you think software developers write the same average amount of lines of code per day ? It seems to me the higher level the language is, higher is the average number of loc per day. IHMO Debugging has an huge impact on this average and lower level languages are harder to debug.
- pcwalton 9y ago
  I have not found Rust any harder to debug than, say, Python. LLDB works fine.
  - dgsb 9y ago
    I have no experience with rust so I can not elaborate on that, but I find harder to debug a multi-threaded C++ application where race condition and memory corruption is possible than a python one. That difficulty has an impact on average daily productivity on LOC.

mathw 9y ago

I disagree. I think Rust is pretty easy once you've spent a bit of time learning about lifetimes. It should be substantially less surprising when it's got non-lexical lifetimes, though. Rust seems to me eminently suited to write high-performance web applications.

pankajdoharey 9y ago
Well anyone is free to think anything, the Rust compiler is by nature very conservative and tries to take an approach where it wants to you put a lot of information so that it is easier for it compile programs and infer right context. In the process it demands a lot from you compared to Go. Being a C fan i would say C is way easier than Rust, but look where C has lead us, huge amount of headache due to tons of unspecified behavior of C which all compiler makers have diligently copied from each other. So i totally get it Rust is great for these scenarios absolutely, write OS Kernel, Databases, Browsers what have you... But it is really not meant for the web, trying to use Rust for web is retrofitting at best.
naasking 9y ago
Let's be serious, Rust will never be as easy to use as a language with GC. It will perform better on many metrics, but you have to pay that cost.
- sqeaky 9y ago
  Unless you care about resources other than memory. GC doesn't help to make sure mutexes don't deadlock and files are closed. As far as I know there is no general purpose algorithm for those.
  - naasking 9y ago
    Even still, you can opt-in to those features in a GC language when you need it, but the contrary is not the case in Rust at the moment.
    - 9y ago

legulere 9y ago

Rust is pretty much runtime-less. There's some unwinding stuff you could see as a runtime. You can simply replace it with a compiler flag. There is a standard library which you might mean, but you can opt out of that as well.