Earlier quoted context omitted.
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.
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.
Rust for the Web
81–90 of 100 posts
Re: Rust for the Web
#82Earlier quoted context omitted.
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.
But you can't opt out of the problems with garbage collectors without dropping the language.
Re: Rust for the Web
#83Earlier quoted context omitted.
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, ....
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 m…
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.
Re: Rust for the Web
#84Earlier quoted context omitted.
> 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 def…
> 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. I don't think the issue is about lexical lifetimes, but I don't have a very good understanding of what that means, either. My issue is that I frequently want to take some data and pass it into two separate functions, but I can't do this unless those functions are designe…
If a function only needs to use some data for a bit, it should borrow it i.e. pass by reference.
And if you need to give ownership of some data to a function, and you also need that data for something else, you have to copy it, so that you can give one copy to a function to do what it wants with, and keep the other one for your own purposes.
Re: Rust for the Web
#85Earlier quoted context omitted.
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 m…
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 a…
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.
Re: Rust for the Web
#86Earlier quoted context omitted.
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 a…
> 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…
Re: Rust for the Web
#87Earlier quoted context omitted.
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 a…
> 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…
I share the opinion of the current thread going on Reddit and Rust forum, that the use cases of C and C++ should be the ones being targeted by Rust.
Everyone else is quite happy using GC based languages, specially on web development.
Re: Rust for the Web
#88Earlier quoted context omitted.
> 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…
Haskell, OCaml, Scala and C++ have a more powerful type system, while being more productive than Rust on its current state. I share the opinion of the current thread going on Reddit and Rust forum, that the use cases of C and C++ should be the ones being targeted by Rust. Everyone else is quite happy using GC based languages, specially on web development.
> Everyone else is quite happy using GC based languages
The huge amount of rustaceans coming from language with GC (including myself) isn't really in favor of your argument.
As a web dev currently using rust for cli tools, I'd be really happy to do my web stuff in Rust also once the web story for rust has matured. And seeing what happened since last year in this field, I'm really optimistic for the future.
I understand that not everybody thinks the way I do, but we exist though ;).
Re: Rust for the Web
#89Earlier quoted context omitted.
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.
Associated types put Rust beyond Java and far beyond Go in terms of type system features, even without counting anything lifetime-related.
Re: Rust for the Web
#90Earlier quoted context omitted.
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.
> 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.