Live data from Hacker News

Rust for the Web

thefullsnack.com

81–90 of 100 posts

Re: Rust for the Web

#81
post #70

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.

But you can't opt out of the problems with garbage collectors without dropping the language.

Re: Rust for the Web

#82
post #81

Earlier 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.

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.

Re: Rust for the Web

#83
post #47

Earlier 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…

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.

Re: Rust for the Web

#84
post #74

Earlier 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 those two functions both need to own the data you're passing in, then they should take it by value, because in Rust passing by value means giving ownership of the data to the thing you're passing it to. It might give it back (as a return value), but that's another matter.

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

#85
post #83

Earlier 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…

> 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.

Re: Rust for the Web

#86
post #83

Earlier 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…

[deleted]

Re: Rust for the Web

#87
post #83

Earlier 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…

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.

Re: Rust for the Web

#88
post #87

Earlier 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.

Haskell and OCaml look alien and are beyond Rust in term of learning curve, and I speak as someone who historically learned OCaml as his first language (just French things). I can't say anything about Scala. I don't know what C++ is doing in this list since there's no GC and its type system doesn't really compare to the other languages discussed here (including Rust).

> 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

#89

Earlier 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.

Interesting, didn't know it had something like type families. Thanks!

Re: Rust for the Web

#90
post #66

Earlier 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.

I meant more complicated.
Post reply on HN