8 ms·

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-

by 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.
    - sqeaky 9y ago
      But you can't opt out of the problems with garbage collectors without dropping the language.
      - naasking 9y ago
        Most common GC "problems" have fairly simple solutions. If we're talking about 50GB+ heaps, then we're already talking about a problem that's getting significant engineering investment, so custom solutions become warranted, ie. a special purpose library that manages its own resources that plugs into the safe runtime, similar to unsafe Rust, just less integrated.
pjmlp 9y ago
Rust will never be as convenient as GC languages for web, GUI and distributed programming. Also just because they have a GC doesn't mean all allocations have to go through the heap. Rust killer area is the low level C stuff, resource constrained embedded devices, device drivers, codecs, ....
- littlestymaar 9y ago
  Affine type system + the borrowck (each value has a single owner & you can't mutate it from more than one place at a time) which are the mechanisms that Rust uses to avoid GC are also a huge help when structuring a program whit predictible behavior : it's the perfect middle-line between imutable data structures (which are slow due to copying and have anoying limitations in many cases) and open-bar mutate-everything models. It's a really powerful feature which helps a lot to have a code easy to understand and to maintain. This is a massive productivity bonus IMHO and no GC will ever give you that. Lifetime annotations (which are the other feature needed by Rust's memory management) are sometime annoying though.
  - pjmlp 9y ago
    A GC is way more productive than the metal effort and programming skills required to master an affine type system, just to put a couple of buttons on the screen talking to a database backend. I had lots of fun going through the Idris and Rust books, but I don't see the average enterprise programmer wanting to deal with it. Surely not the ones that I know, that don't have any idea what Idris, Rust or even HN are all about. Which is why D, Swift, C++, Pony designers are looking into Rust, taking some of its ideas, and blending them with GC + dataflow analysis.
    - littlestymaar 9y ago
      > A GC is way more productive than the metal effort and programming skills required to master an affine type system Ease of learning and productivity are two different things. Rust is indeed harder to learn than JavaScript, but IMHO it's more productive in a day-to-day use thanks to its powerful type system (caveat, the ecosystem is still pretty young). Swift is harder to use than Rust in my opinion since you have to deal with cyclic references to avoid memory leak with ARC.
weberc2 9y ago
I disagree. :) I have experience in low level programming and several MLs (and lots of misc other languages), so I don't think my opinions are shaped solely by familiarity. There is a lot to like about Rust, but here are some things that I think make rust hard (and I think the difficulty of these features outweigh any productivity granted by the safety features). First, the affine type system--I don't understand the use case for pushing ownership deeper into the stack by default, and it seems crazy that I have to know how all instances of a given type will be passed at definition time. It doesn't seem to facilitate safety, or at least it seems like the most flat-footed approach to preventing double-frees (never let two functions access the same memory, even those that can be trivially proven to run sequentially). I literally never want to move--I always want to shallow copy (or reference). Further, you can't call most pass-by-value functions from inside a pass by reference function because the former usually wants to destroy the value. Copy works around this in the simplest cases, but for the most part you end up with two categories of classes that can't be mixed. This is especially bad for open traits, where the trait definition has to decide how all implementations will pass and receive their arguments. Beyond that, when defining a struct type that holds a reference, you have to know at definition time the lifetime of that reference, even it may vary from instance to instance (sometimes I want the struct to own the reference, but sometimes I don't). Maybe there's a way to express this in Rust, but it seems like the default is to assume that lifetimes are part of the type. This creates another dichotomy in types: those that own their data and references to data (String vs STR, vec vs slice, etc). I like Rust. I love that it's an ML with a sane syntax, or a C-family language with decent functional features and sum types. I just can't justify these impediments. :(
- wtetzner 9y ago
  > it seems like the most flat-footed approach to preventing double-frees (never let two functions access the same memory, even those that can be trivially proven to run sequentially) This might just be a case of needing non-lexical lifetimes. I'm not sure about that, because I don't know the details of what issues you ran into. > Beyond that, when defining a struct type that holds a reference, you have to know at definition time the lifetime of that reference, even it may vary from instance to instance (sometimes I want the struct to own the reference, but sometimes I don't). The main issue I run into is when I want a struct to own a value, and for that struct to also include a reference into that value.

by mathw 9y ago

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.
  - sqeaky 9y ago
    But you can't opt out of the problems with garbage collectors without dropping the language.
    - naasking 9y ago
      Most common GC "problems" have fairly simple solutions. If we're talking about 50GB+ heaps, then we're already talking about a problem that's getting significant engineering investment, so custom solutions become warranted, ie. a special purpose library that manages its own resources that plugs into the safe runtime, similar to unsafe Rust, just less integrated.

pjmlp 9y ago

Rust will never be as convenient as GC languages for web, GUI and distributed programming. Also just because they have a GC doesn't mean all allocations have to go through the heap. Rust killer area is the low level C stuff, resource constrained embedded devices, device drivers, codecs, ....

littlestymaar 9y ago
Affine type system + the borrowck (each value has a single owner & you can't mutate it from more than one place at a time) which are the mechanisms that Rust uses to avoid GC are also a huge help when structuring a program whit predictible behavior : it's the perfect middle-line between imutable data structures (which are slow due to copying and have anoying limitations in many cases) and open-bar mutate-everything models. It's a really powerful feature which helps a lot to have a code easy to understand and to maintain. This is a massive productivity bonus IMHO and no GC will ever give you that. Lifetime annotations (which are the other feature needed by Rust's memory management) are sometime annoying though.
- pjmlp 9y ago
  A GC is way more productive than the metal effort and programming skills required to master an affine type system, just to put a couple of buttons on the screen talking to a database backend. I had lots of fun going through the Idris and Rust books, but I don't see the average enterprise programmer wanting to deal with it. Surely not the ones that I know, that don't have any idea what Idris, Rust or even HN are all about. Which is why D, Swift, C++, Pony designers are looking into Rust, taking some of its ideas, and blending them with GC + dataflow analysis.
  - littlestymaar 9y ago
    > A GC is way more productive than the metal effort and programming skills required to master an affine type system Ease of learning and productivity are two different things. Rust is indeed harder to learn than JavaScript, but IMHO it's more productive in a day-to-day use thanks to its powerful type system (caveat, the ecosystem is still pretty young). Swift is harder to use than Rust in my opinion since you have to deal with cyclic references to avoid memory leak with ARC.

weberc2 9y ago

I disagree. :) I have experience in low level programming and several MLs (and lots of misc other languages), so I don't think my opinions are shaped solely by familiarity. There is a lot to like about Rust, but here are some things that I think make rust hard (and I think the difficulty of these features outweigh any productivity granted by the safety features). First, the affine type system--I don't understand the use case for pushing ownership deeper into the stack by default, and it seems crazy that I have to know how all instances of a given type will be passed at definition time. It doesn't seem to facilitate safety, or at least it seems like the most flat-footed approach to preventing double-frees (never let two functions access the same memory, even those that can be trivially proven to run sequentially). I literally never want to move--I always want to shallow copy (or reference). Further, you can't call most pass-by-value functions from inside a pass by reference function because the former usually wants to destroy the value. Copy works around this in the simplest cases, but for the most part you end up with two categories of classes that can't be mixed. This is especially bad for open traits, where the trait definition has to decide how all implementations will pass and receive their arguments. Beyond that, when defining a struct type that holds a reference, you have to know at definition time the lifetime of that reference, even it may vary from instance to instance (sometimes I want the struct to own the reference, but sometimes I don't). Maybe there's a way to express this in Rust, but it seems like the default is to assume that lifetimes are part of the type. This creates another dichotomy in types: those that own their data and references to data (String vs STR, vec vs slice, etc). I like Rust. I love that it's an ML with a sane syntax, or a C-family language with decent functional features and sum types. I just can't justify these impediments. :(

wtetzner 9y ago
> it seems like the most flat-footed approach to preventing double-frees (never let two functions access the same memory, even those that can be trivially proven to run sequentially) This might just be a case of needing non-lexical lifetimes. I'm not sure about that, because I don't know the details of what issues you ran into. > Beyond that, when defining a struct type that holds a reference, you have to know at definition time the lifetime of that reference, even it may vary from instance to instance (sometimes I want the struct to own the reference, but sometimes I don't). The main issue I run into is when I want a struct to own a value, and for that struct to also include a reference into that value.