Live data from Hacker News

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

211–220 of 511 posts

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

#211
post #113
post #6

Earlier quoted context omitted.

> Want to concat an number and string ? JavaScript wont complain. Is that supposed to be an endorsement?

foo = (string, number) => string + number Now go write that in your preferred language!

Why would I want to? Better to explicitly convert the number to a string.

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

#212

still compiles too slowly, a language in 2016 just cannot take multiple seconds for me to use it add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

We had significant compile-time improvements in the release yesterday, with more to come in the future. Also, you might want to give incremental recompilation a try, it's nightly-only for now, but being actively worked on. > add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average. It should not recompile those crates each time, if it does, that's a bug. Please report them!

> It should not recompile those crates each time, if it does, that's a bug. Please report them!

Depends on the inter-crate dependencies, alas. Touching one crate can easily cause multiple other crates to rebuild.

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

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

Wouldn't it be more useful to fail with an error message at least ?

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

#214
post #96
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 ?

There isn't actually a trade-off between efficiency and ease of use across all languages. For example, JavaScript is both slow and memory hungry while also being inconvenient to use.

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

#215

Earlier quoted context omitted.

I think the idea is to fail to compile if you have certain kinds of panic? I agree that making unwrap/expect silently ... not happen will just cause worse problems.

Sure, but in that case it would effectively elide it from the language spec! Who doesn't target "production" eventually?

> Sure, but in that case it would effectively elide it from the language spec!

No. Some unwraps are necessary. You wouldn't be absolutist here; you could still allow some carefully-labeled unwraps.

Also, not all production users need to care about panics that much.

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

#216

Earlier quoted context omitted.

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

Not OP, but as someone who theoretically would like Rust - I'll bite. Maybe my usecase is a common one. I understand memory management in C. I understand it modern C++ (destruction when going out of scope, smart pointers etc). Basically, a description and discussion of borrow-checking for people who have already used system programming languages would be really helpful. I feel like the book is targeting people who ha…

Have you tried looking at https://github.com/nrc/r4cppp ?

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

#217
post #204

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.

It was new in Swift 2 I think. Didn't use it yet. But it's basically a single case statement lifted from switch, nothing more. But enums and switch statements can be really complex beasts by themselves in Swift.

If Rust only allows it on enums that would be extremely weird.

In a switch statement I sometimes want to switch on the object, then see if I'm allowed to unwrap it to a certain class and immediately use it afterwards. Useful for parsing an array of mixed object types that should be processed differently.

But I honestly think Swift allows people to write elaborate illegible codegolf-y bullshit sometimes. Sometimes the Swift compiler still chokes on too complex expressions and you need to add some explicit types or separate out in several statements what you were trying to do in one statement. Usually a good warning that your code is hard to read even by humans.

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

#218
post #55
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. It would, and definitely should, move into the direction of safer languages than C. The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the co…

Rather than a ground-up rewrite, I expect people will begin using Rust in the same way that Firefox has: identify individual components that would most benefit from Rust, segment those components off behind well-defined C interfaces, then write a compatible Rust lib using Rust's ability to expose C interfaces.

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

#219
Congrats to all the Rust team!

Love the zero-cost abstraction approach, love the good practice compiler warnings, love the cargo ecosystem, love the markdown code dox that tests the example code.

First time I actually enjoyed reading a programming language's documentation.

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

#220

Earlier quoted context omitted.

It's worth mentioning that there are several strategies for avoiding cascading deallocations like arenas or arena-backed graph abstractions. For example: https://crates.io/crates/typed-arena https://crates.io/crates/petgraph Rust's generics make this fairly pleasant to work with, and lifetimes/borrowck ensure safety when managing your own object allocations.

Indeed, if you can live with the wasted memory use of objects outliving their conceptual lifetime, regions/arenas are a good solution. Note however that you'd probably still have to run destructors when destroying an arena (to free file handles for instance), so you can still see high latency. With an arena you can perhaps schedule this better though.

> if you can live with the wasted memory use of objects outliving their conceptual lifetime, regions/arenas are a good solution.

If you can live with the wasted memory use of objects outliving their conceptual lifetime, garbage collectors can be a good solution too.

Not that that's a bad thing for many use cases, but your above comment implies a comparison between Rust and GC. I think the quoted critique falls down a bit when Rust lets you opt-in to generational-esque GC-ish behavior with a very similar downside to what you'd get from a GC.

Post reply on HN