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

201–210 of 511 posts

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

#201

Post by bsder »

steveklabnik wrote: post #168
bsder wrote: post #160

Earlier quoted context omitted.

Sure, but the question is how wide the "unsafe" boundaries are. If I'm writing an application that uses the network in a standard way, I should be able to write a program with NO unsafe blocks. As always, things have bugs. Rust, itself, may have bugs that get exposed over time once adoption starts to increase. Rust gets some "security through obscurity" for the moment. Once they start pushing Rust code into Firefox,…

There's already a small amount of Rust in Firefox.

That's really cool, and I'm glad to hear it.

As it expands in the Firefox codebase, it gives me the ability to tell people that "Yes, Rust is being used by lots of people".

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

#202

Post by rweichler »

jokoon wrote: post #147
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

A good language should be like a good game: easy to learn, hard to master. We don't care about expert cases, we only care about getting productive ASAP, which means having students hoping into a language and learning it quickly. Solving the details is easy: just teach coding discipline and enforce good practice and do code reviews, and discourage "throwable" code. Security is not only the job of a programmer, it has…

LuaJIT + C have suited me just fine for systems programming. I don't care about security, so I find it hard to care about Rust. All I care about is lessening the burden on me as a programmer.

I think Rust may be useful in cases like ripgrep, where you basically rewrite an existing, established tool or service used by many to be as performant and secure as possible. But other than that niche use-case, I don't think Rust will catch on in the long-term.

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

#203

Post by brandur »

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/

I've had good luck so far with Vim + You Complete Me [1] (which uses a Racer background).

Check the GIF in its repo, but it gets you code completion boxes in Vim that pop up automatically in which you can tab through for the next results. It's very ergonomic compared to Vim's awkward built-in completion shortcuts, and gives you completion intelligence that's trending towards something like Visual Studio + C#.

[1] https://github.com/Valloric/YouCompleteMe

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

#204

Post by kibwen »

AsyncAwait wrote: post #192
dep_b wrote: post #161

Earlier quoted context omitted.

Isn't if let similar to Swift's if let where it either unwraps safely or does something else? I really wish I could disable forced unwrapping as it mostly leads to mistakes by less experienced or overconfident programmers and the amount of extra code by using guard instead if you program smart is negligible.

Rust's if let is indeed inspired by that of Swift and behaves practically the same way.

Though Swift's `if let` is AFAIK hardcoded to their built-in optional type, whereas when Rust lifted the idea they made it work with any enum. I believe Swift recently gained `if case let` as an equivalent to how `if let` works in Rust.

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

#205

Post by naasking »

worik wrote: post #198
naasking wrote: post #110

Earlier quoted context omitted.

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

"C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well." But you have to code them. They are predictable, or you let them in by allowing data structures to grow indefinitely With C you can make latency guarantees. You can write code that does not have such guarantees but it is your choice With GC you are not in control so there are fewer choices. You will not be able to m…

> With GC you are not in control so there are fewer choices. You will not be able to make guarantees.

Not true. Hard and soft realtime GCs with sub-microsecond latencies exist. Latency is a property of a runtime, not of manual vs. automatic storage reclamation.

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

#206

Post by nnethercote »

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 you click the "[-]" symbol at the top right of a docs page it collapses all the text and just shows the method signatures. Then you can click the "[+]" symbol next to any single method to get full details.

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

#207

Post by steveklabnik »

kibwen wrote: post #204
AsyncAwait wrote: post #192

Earlier quoted context omitted.

Rust's if let is indeed inspired by that of Swift and behaves practically the same way.

Though Swift's `if let` is AFAIK hardcoded to their built-in optional type, whereas when Rust lifted the idea they made it work with any enum. I believe Swift recently gained `if case let` as an equivalent to how `if let` works in Rust.

Any unrefutable pattern, I believe.

EDIT: whoops! I got it backwards. It's refutable, right, duh. :)

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

#208

Post by quotemstr »

IshKebab wrote: post #200
quotemstr wrote: post #199

I lament what Rust could have been had its designers not jumped on the anti-exception bandwagon. Rust's error handling is bad and makes me prefer C++

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.

Also, in Rust since we can panic, we need to worry about exception anyway! Rust has the worst of both kinds of error handling.

Exceptions are anti verbosity: you're supposed to let them propagate, not catch and rethrow them. They don't erase context: they preserve it, since an exception object is constructed as close as possible to the error site that caused it.

I realize that I have a minority view, but I'm utterly convinced that I'm right and that I'm living in a world gone mad. I've written a ton of code over the years. At least hear me out and try to understand my perspective.

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

#209

Post by kibwen »

josephg wrote: post #163
rwj wrote: post #150

Earlier quoted context omitted.

I think the idea would be the program would fail to compile, and you would need to go back and replace the unwrap with proper error handling. The goal would be to allow the use of unwrap during development, but require the final polish before the code goes into production.

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

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

#210

Post by steveklabnik »

Skalman wrote: post #190
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

For me the hump was from the get-go. Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.

Rustup has been in beta for a while, which is why we don't recommend it in the book. Soon though!
Post reply on HN