Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for the Web

thefullsnack.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Rust for the Web

#71

Post by wtetzner »

weberc2 wrote: post #62
mathw wrote: post #37

Earlier quoted context omitted.

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.

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…

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

Re: Rust for the Web

#72

Post by wtetzner »

moomin wrote: post #66
pjmlp wrote: post #64

Earlier quoted context omitted.

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

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.

Re: Rust for the Web

#73

Post by RussianCow »

Drdrdrq wrote: post #50
RussianCow wrote: post #13

Just a small nitpick, but #3 is not actually an isomorphic app, it's just a regular server-rendered one. Isomorphic typically means that the app is rendered in the same way (e.g. via React) on both the frontend and backend, and the frontend degrades gracefully when JS isn't enabled. More on-topic: I just recently started a new web app using Rust on the backend. Though there is definitely a lot still missing, it's ama…

> I expect that within a couple years, Rust will be a viable alternative to Python and Ruby for backend web development I like Rust, but I don't see this happening. Python, Ruby and PHP/Node.js languages became popular (and thus useful) because their learning curve is not steep - which is not something one can say about Rust. I consider myself capable developer but I struggled with many concepts. It's true that I did…

That's true, and I don't mean to imply that I think it will replace Python/Ruby/etc. But I think Rust may find a sizeable niche as a high-performance, lower-level backend programming language for the web, sort of like Elixir. I've personally found the learning curve to be a lot smaller for web development than other projects because you don't have to learn everything at once; web development doesn't typically call for things like manual threading, so the borrow checker and other advanced features don't come up nearly as much or as early as they might for other codebases.

Re: Rust for the Web

#74

Post by weberc2 »

wtetzner wrote: post #71
weberc2 wrote: post #62

Earlier quoted context omitted.

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…

> 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 designed to take the value by reference. Even if those values contain owned references into the heap, the programs can be trivially proven to be correct. I can work around this by always passing references, but it seems strange to use reference semantics when all I really want is to not destroy the original value.

Another common case is that I have a borrowed reference that points to data I would like to pass (by value) into another function: `fn foo(bar: &Bar) { baz(bar.x) }`.

Re: Rust for the Web

#75

Post by moomin »

wtetzner wrote: post #72
moomin wrote: 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.

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.

Re: Rust for the Web

#76

Post by legulere »

pankajdoharey wrote: post #19

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…

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.

Re: Rust for the Web

#77

Post by wtetzner »

weberc2 wrote: post #74
wtetzner wrote: post #71

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…

> Even if those values contain owned references into the heap, the programs can be trivially proven to be correct.

I don't think that's true. Passing data to a function when it's not a reference means that you're giving ownership to that function. How could you then pass it to another function (unless the first returned it again)? Once a function has ownership, it means nothing else has ownership of the data.

Basically, if you write a function that just takes a value, and doesn't take a reference, then you're telling your callers to give you ownership. If you don't want to take ownership, then just always accept a reference.

Maybe I'm misunderstanding the problem you're having. Do you have an example of another language that lets you do what you want?

Re: Rust for the Web

#78

Post by littlestymaar »

pjmlp wrote: post #47
mathw wrote: post #37

Earlier quoted context omitted.

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.

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

Re: Rust for the Web

#79

Post by littlestymaar »

anhtran wrote: post #18

Rust is cool. But I don't think it's good for web backend at this time. I will try it when working with WebAssembly.

I don't understand why you are downvoted : that's absolutely true, Rust isn't quite the best choice for web backend ATM, by far.

It's way better than last summer though, rocket and the recently announced gotham framework look great, and I'm really excited to see how it evolves in the next few months.

Re: Rust for the Web

#80

Post by naasking »

sqeaky wrote: post #70
naasking wrote: post #43

Earlier quoted context omitted.

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.

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.
Post reply on HN