Rust and the Future of Systems Programming [video] • Hacker News Board

Re: Rust and the Future of Systems Programming [video]

#121

Post by wyldfire » Wed, Nov 16, 2016, 7:50 PM UTC

tmzt wrote: post #49

pimeys wrote: post #19

Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam... I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugl…

Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"

Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link() failed!

Tangent: errors and exceptions aren't bad, they're how computers work. I've encountered folks who, when faced with runtime errors pepper their code with "if (!NULL)" or truly evil things like "except:pass"/"catch (...) { }" which rarely make sense anywhere but the base of the stack and even then don't usually. If you've ever asked yourself "but how did we even get here‽" it may be because someone dropped something totally incongruous like that in a related module.

Re: Rust and the Future of Systems Programming [video]

#122

Post by swuecho » Wed, Nov 16, 2016, 7:50 PM UTC

djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

same feeling here. There are docs here and there, but not good.

I am waiting a good book on rust. similar to Haskell, I really did not get much until the book http://learnyouahaskell.com/

currently, "The book" is too dry.

Re: Rust and the Future of Systems Programming [video]

#123

Post by qwertyuiop924 » Wed, Nov 16, 2016, 7:51 PM UTC

naasking wrote: post #115

qwertyuiop924 wrote: post #103

Earlier quoted context omitted.

Rust itself can't, but you as the programmer can. It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.

Absolutely, you have to be aware of the ownership graph depth in both C and Rust if you want to bound latency. You don't have to do this with tracing GC though, you just need a runtime that implements latency bounds.

Wait, why would you have to do that? Most ownership is determininstically resolved at compile time, so you can know exactly when a resource will be freed. What you do have to know is about the rare refcounted variable, and what edge cases require ownership checking at runtime.

Re: Rust and the Future of Systems Programming [video]

#124

Post by AsyncAwait » Wed, Nov 16, 2016, 7:51 PM UTC

thewhitetulip wrote: post #63

gcp wrote: post #43

Earlier quoted context omitted.

A project like Servo means that the proof will be in the pudding. Gecko and WebKit/Blink are C++ (though stuck at C++11 due to compiler and platform compatibility). So we'll see how they end up comparing.

I really wish that they replace Firefox with a browser written using Servo. That'll be fun.

They're putting components from Servo inside Firefox. Servo is not yet at the point where it can full sale replace Gecko, but it's getting there.

Re: Rust and the Future of Systems Programming [video]

#125

Post by cderwin » Wed, Nov 16, 2016, 7:51 PM UTC

Thaxll wrote: post #90

CodeMage wrote: post #56

I'd love to see someone write a game engine in Rust to compete with the "big boys" like Cry or Unreal. C++ game code can be such a nightmare.

Not going to happen in the next 10 years, everything is built around C++. And tbh I don't see what would games benefit from using Rust instead of C++.

I've never worked on anything gaming related, but the bigger cross-platform games certainly have crashes. I can't even tell you how many times Fallout 4 has crashed for me (likely hundreds). I obviously don't know if rust could help, but it's not unreasonable to think it might.

Re: Rust and the Future of Systems Programming [video]

#126

Post by dagmx » Wed, Nov 16, 2016, 7:52 PM UTC

djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

Have you tried: http://rustbyexample.com/

Re: Rust and the Future of Systems Programming [video]

#127

Post by wyldfire » Wed, Nov 16, 2016, 7:52 PM UTC

cbHXBY1D wrote: post #102

steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

Not specifically about your book, but I would love if there was a quicker way to find methods in the docs. Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.

If I don't find what I'm looking for from the docs, I often use ripgrep on a copy of the rust repo locally to find answers.

Re: Rust and the Future of Systems Programming [video]

#128

Post by steveklabnik » Wed, Nov 16, 2016, 7:54 PM UTC

naasking wrote: post #110

Rusky wrote: post #98

Earlier quoted context omitted.

Lifetimes are compile-time only and do not do any reference counting. So Rust has the same latency guarantees as C, for example.

> Lifetimes are compile-time only and do not do any reference counting. I never said they did, I said lifetimes and reference counting both have this pathological case. C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well. It's a total myth that you need C in realtime domains due to "latency". Maximum pause times are a property of a particular runtime , not a language.

What is the pathological case with lifetimes? You're saying it takes "time proportional to the number of dead objects to free", but as the parent said, lifetimes are a compile-time construct, so they have no runtime properties.

(I'm not saying that for sure there are none, I'm saying that it seems like you're talking about refcounting only, the lifetime bit is unclear to me.)

Re: Rust and the Future of Systems Programming [video]

#129

Post by Manishearth » Wed, Nov 16, 2016, 7:55 PM UTC

naasking wrote: post #91

wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. EDIT: I mean to say that many of my colleagues who write realtime software…

> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free. Copying collec…

> Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free.

Rust doesn't use reference counting by default. Refcounting is very rare in Rust, much more rare than it is in C++. Most large C++ codebases I've worked with have thrown in the towel and started refcounting all the things. In Servo, for example most of the refcounting is across threads (where you basically have no other option), and a few interesting cases in the DOM, each with very good reasons for using refcounting.

Lifetimes are a concept at compile time and don't exist at runtime.

Edit: Oh, I see what you're talking about. A sufficiently large owned tree/graph in Rust will introduce latency. It's predictable latency though. I can make the same argument about for loops.

Unpredictably sized large trees in Rust are again pretty rare in general.

Re: Rust and the Future of Systems Programming [video]

#130

Post by steveklabnik » Wed, Nov 16, 2016, 7:55 PM UTC

q3r3qr3q wrote: post #101

steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

I'd get excited and go through some tutorial on their website, probably the main? tutorial, bu then when you get to the lifetimes section is seemed to get really complicated instantly. I tried twice and think I hit the same problem. Maybe some more good examples would help?

Makes sense! I'm working on a second draft of the book right now, and it's making that stuff more clear. http://rust-lang.github.io/book/ is the draft; the lifetimes bit hasn't landed yet though.