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

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

271–280 of 511 posts

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

#271

Post by Animats »

Manishearth wrote: post #129
naasking wrote: post #91

Earlier quoted context omitted.

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

Trees don't have to be refcounted in Rust. Single-ownership trees are possible. As long as they don't have backpointers. Backpointers are a problem under single ownership.

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

#272

Post by tupshin »

quotemstr wrote: post #208
IshKebab wrote: post #200

Earlier quoted context omitted.

Seriously? Rust's error handling is great, and frankly I'm glad that exceptions have gone out of favour. I tried them but they never really delivered their promise. At their best they do is give you nice stack traces. At their worst they make error handling stupidly verbose, they erase the context you need to properly handle errors, and they make it much more difficult to even know which errors can occur! Rust's solu…

I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking. The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before. Als…

Personally I love Rust's error handling, but I do think that I understand your perspective.

At least part of your objections would seem to be addressed by the combination of the ? operator to make it trivial to do the equivalent of re-throwing inline, and the error-chain crate, which can make exception-like stack traces/etc trivial to implement.

https://brson.github.io/error-chain/error_chain/index.html

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

#273

Post by sctb »

cpeterso wrote: post #162
sctb wrote: post #94

Earlier quoted context omitted.

We've asked you specifically not to do this, so we've banned this account.

Does HN no longer hellban accounts?

We'll quietly ban serial trolls or outright spammers, but otherwise we provide an explanation so that the community can benefit from observing the application of the guidelines. We have other tools for dealing with accounts created as a result of the apparent ban.

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

#274

Post by tome »

jstimpfle wrote: post #177
alkonaut wrote: post #148

Earlier quoted context omitted.

Being able to cut corners with code hygiene works both ways though for productivity: you don't want to realize a week before a deadline that you have a hard-to-find memory leak or crash. A lot of the time it feels like rust development is slow because you are fighting the compiler. On the other hand once you run the program you often get that Haskell-y "it worked because it compiled" feeling. With a normal OO languag…

I haven't experienced that feeling for anything but toy programs. But concerning productivity: fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them. I'm not aware of any type corsets that I think force good designs. In a really clean design mistakes are not terribly hard to fix, even in a language like C. Granted in C they are in so…

> fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them.

Citation needed!

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

#275

Post by jdub »

harveywi wrote: post #64

The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts? [1] https://areweideyet.com/

For the last few weeks, I've been doing all my Rust hacking in Visual Studio Code + the RustyCode extension on both Windows and Mac. It's a good experience, but the (currently early in development) Rust Language Server will make it superb.

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

#276

Post by dbaupp »

Animats wrote: post #257
kibwen wrote: post #22

Earlier quoted context omitted.

Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: http://seanmonstar.com/post/153221119046/introducing-reqwest

Not sure what to think of that. Does everything have to be async I/O now? How often do you need massive numbers of client connections?

I assume you're talking about why reqwest is necessary (i.e. why hyper is moving to async), rather than the single paragraph mentioning asynchronicity as a possible future direction for reqwest?

Async I/O is important for more than just multiplexing a million requests. Hyper is moving to it for that purpose, and also because it is a more natural way for working with in-flight I/O, e.g. cancelling requests or selecting over them.

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

#277

Post by kzrdude »

gue5t wrote: post #175
steveklabnik wrote: post #158

Earlier quoted context omitted.

This is not true. For example, consider this code: if foo.is_some() { let foo = foo.unwrap(); } else { // other code } Here, I _know_ that foo is some. The extra error message from expect will _never_ be seen. Now, this is a contrived example, and would better be written with `if let` in today's Rust, but this is the _kind_ of situation in which unwrap is totally, 100% cool, but the compiler can't know.

The error message in this case might be something like "foo became None after verifying it to be Some". This could happen, for example, if incorrect unsafe code in another thread concurrently mutates foo through a raw pointer. My point is that of course while writing them you don't think your unwraps will fail, but if they do, it's good to have a reminder of what's going on. Even if the expect never fails, the messag…

You'll like Rust, because concurrent mutation of a value is impossible if you hold a `&` or `&mut` to the value. So this can in fact be ruled out by the programmer.

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

#278

Post by naasking »

Matthias247 wrote: post #250
naasking wrote: post #179

Earlier quoted context omitted.

> You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use Not true, soft and hard realtime garbage collectors exist. Your runtime simply needs to bound the amount of reclamation work done at any given time. For instance, the cascading free behaviour Rust is currently susceptible to can be b…

> Your runtime simply needs to bound the amount of reclamation work done at any given time. Wouldn't this transform the problem into a "no more predictable maximum memory usage" problem? As you can't really know if and when your GC will keep up it with the amount of work to do.

Possibly, but maximum memory usage is rarely predictable anyway. I expect it might be even less predictable than maximum latency.

However, it may still be possible to conservatively bound your maximum memory usage too, as long as your reclamation-work phase keeps up with your program's allocation rate, then you achieve a steady-state.

Suppose some amount of reclamation is done on malloc(), a tunable parameter could measure the ratio of allocation speed of the running program and amount of unreclaimed garbage. This ratio would control how much reclamation work to do before returning from malloc() so you can fall into steady-state.

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

#279

Post by Manishearth »

naasking wrote: post #269
Manishearth wrote: post #244

Earlier quoted context omitted.

> Rust people no doubt expect deterministic destruction on scope exit. Deterministic destruction, but not deterministic deallocation :)

But this expectation is transitive. If you have an array of file handles, if you defer deallocating some of them but destruct them all upfront, you still have the latency issue we've been discussing. And if you defer destructing too, then you still have non-deterministic destruction and deallocation. I'm not sure there's a way around this tradeoff.

Right, I already mentioned this a couple of comments ago.

You can use various arena-like structures where you explicitly forgo the guarantee of deterministic drop for this.

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

#280

Post by staticassertion »

kibwen wrote: post #209
josephg wrote: post #163

Earlier quoted context omitted.

unwrap is proper error handling. It says "Try to do this. If it fails, panic". Its like an assert on an invariant that the compiler requires. If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. If I wrote that logic myself I would just be awkwardly rewriting unwrap.

To be more accurate, unwrap can be a legitimate means of error handling when used in an application, as opposed to a library. But if you're writing a library, then unwrapping rather than using Result is a surefire way to make your users hate you. :)

Even in a library there are valid use cases for an unwrap. If you can literally guarantee that the value is present it's fine.

In libraries one should be wary about it, and never use it if the unwrap might actually panic, but otherwise you're good to go.

Post reply on HN