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

231–240 of 511 posts

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

#231

Post by alkonaut »

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…

Having to fight the compiler over reasonable code that the compiler doesn't like will happen with any type system, you don't need one with lifetimes to have that. The question is of course where to draw the line (where the drawbacks outweigh). I really like how you opting out of the guarantees, e.g. to initialize a doubly linked pointer you might just drop to unsafe because you can overview the memory safety implications of those two lines, but not the whole program.

How effective (and thus popular) Rust will be for creating large systems on tight deadlines remains to be seen I suppose - if it isn't competitive with C++ in that respect, then I'd consider that a failure. And a surprise.

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

#232

Post by burntsushi »

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?

To put this into perspective, this would also necessarily disable expressions of the form `xs[i]` where `xs` is a slice. Why? Because `xs[i]` is equivalent to `*xs.get(i).unwrap()`.

In other words, banning unwrap isn't really that productive because an unwrap, when properly used, is an expression of a runtime invariant.

The problem is that unwrap can be very easily misused as an error handling strategy in a library, and in that case, it's pretty much always wrong. But that doesn't mean using unwrap in a library is wrong all on its own, for example.

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

#233

Post by [deleted] »

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.

[deleted]

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

#234

Post by takeda »

z3t4 wrote: post #96
0xAA55 wrote: post #7

Earlier quoted context omitted.

Want to make a fast application on a pebble and with actual type checking? C and Ada won't complain or blur your lines... http://blog.adacore.com/make-with-ada-formal-proof-on-my-wri...

And real programmers write in machine code. Want to get shit done ? Most systems now a day has more then 20kb RAM! Where do you draw the line between systems programming and non system programming ? And why not write some quick and dirty code in say JavaScript and then do what needs optimization in C/assembly ? Assuming you are not restricted to a CPU that cost less then a dollar. And where does Rust come in ?

With smart watches we still have problems, mainly to hold enough power. Yes, Pebble can last a week, but that's because it is running less resource intensive hardware, and even then 1 week is still laughable when comparing to old watches that require battery change once per 2 years.

By being more conservative, you can achieve more with less resources.

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

#235

Post by nostrademons »

shriek wrote: post #143
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'm also in a similar boat but my primary thing being that I learn by doing and since it's branded as "system programming" I immediately think of big projects like kernels and drivers. I wish there were some small projects that I could do apart from just doing "project euler" that would be helpful to me. I even bought raspberry pi to learn rust but don't quite know what to do with it and rust.

There are a large number of projects on Cargo that maybe-perhaps do something useful, but don't get much love in the testing/documentation/polish department since the authors tend to move onto other projects. My personal wish list:

Varints: https://crates.io/crates/varint

Bloom filters: https://crates.io/crates/bloom

Iron: https://github.com/iron/iron

All the accessories for Iron: authentication middleware, integration with OAuth2, cookie-signing, integration with templating systems, etc. Also, an omakase framework (like Django or Rails) that pulls together a bunch of useful libraries into one crate that you can just use (with good docs) and not have to wire everything up.

Websockets: https://github.com/cyderize/rust-websocket or https://github.com/housleyjk/ws-rs

Server-sent events. I don't see a good alternative for these yet.

ElasticSearch: https://github.com/benashford/rs-es or https://github.com/erickt/rust-elasticsearch or https://github.com/KodrAus/elasticsearch-rs

An easy documentation/website generator for small libraries, that pulls examples, tests, and README files out of GitHub, runs RustDoc, and generates a professional-looking website that provides all the info that you need to get started with a library, with a minimum of extra effort for the library author. Basically, automate the job of going through libraries built to scratch someone's personal itch and "productizing" them.

Any of these could be a good project for a beginner, since there's already a lot of existing code to learn from, a small well-defined task, and an existing maintainer who has an incentive to help. Basically, just take a library, try to use it in a small test program (Linus's Law: "Never try to make a big important program. Always start with a small trivial program, and work on improving it"), and if anything is difficult or doesn't work right, figure out how to make it less difficult for the next person who runs across it and submit a pull request with that. As an added bonus, you can learn a lot of domain knowledge or basic CS data structures through digging through this, and that transfers to programming outside of Rust.

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

#236

Post by xorxornop »

wyldfire wrote: post #138
tmzt wrote: post #93

Earlier quoted context omitted.

Right, it would likely use clippy but it would essentially be a --production target or profile, intended for builds where the binary will be run in production. And by 'and friends' I mean calls that panic for the same reason as unwrap, such as expect or ok. The goal is to stop code from reaching production inadvertently, not to prevent all sources of panics.

But if we accept the premise that "it's acceptable in some cases to have unwrap() in code that targets 'production'" then it wouldn't make sense to have a production profile that bars its use. The word "production" is in the global namespace and I think you want something more specific to your use case. Rather, one could define a rust coding guide for themselves that deems unwrap() inappropriate for production use. (…

Seems like you'd want a lint rule where if unwrap is used, it must have a comment preceding it (of some formal syntax) describing why it's necessary or appropriate. Thus the build can have all uses of unwrap known as explicitly allowed, allowing all the possible sites of panics to be enumerated and known, a useful property to have

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

#237

Post by gue5t »

steveklabnik wrote: post #207
kibwen wrote: post #204

Earlier quoted context omitted.

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

If-let can be used with refutable patterns (the refutation/counterexample to the pattern is when the else case runs). Irrefutable patterns can be used with regular let.

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

#238

Post by tomjakubowski »

steveklabnik wrote: post #207
kibwen wrote: post #204

Earlier quoted context omitted.

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

Any refutable pattern; for irrefutable patterns the "if let"'s pattern would always match, so it would be kinda redundant. :-)

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

#239

Post by AsyncAwait »

enqk wrote: post #187
AsyncAwait wrote: post #153

Earlier quoted context omitted.

I don't get what you're saying here. - Without Rust you program to protect users assets without guaranteed memory safety. - With Rust you program to protect users assets, with the addition of guaranteed memory safety. Sounds like a win win to me.

Indeed it is a good thing. What I'm just a little bit weary of is equating that sort of improvement with increasing overall security. We went there already with Java and this hasn't stopped Java from being an attack vector. The way this sort of reasoning affects the behavior of engineers and the products they put out in front of users.

I get that you don't want developers to learn the bad habit of believing that Rust means they no longer need to pay any attention to security themselves, but that doesn't negate the fact that Rust does indeed increase some aspects of your program's security as compared to C.

The security provided by Rust shouldn't be overestimated, but I think it's unfair to underestimate the benefits of the memory safety as well.

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

#240

Post by naasking »

Manishearth wrote: post #224
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…

> For instance, the cascading free behaviour Rust is currently susceptible to can be broken up into a bounded series of free operations interleaved with ordinary program execution. You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs. This won't reduce the perf impact of running a large tree of `Drop` imp…

> You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs.

That gets tricky, because Rust people no doubt expect deterministic destruction on scope exit. But yes, my ultimate point is that low latency is a property of a runtime, not a language. C/C++ or Rust aren't going to automatically give you bounded latency, and adding tracing GC doesn't automatically take it away.

Post reply on HN