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

191–200 of 511 posts

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

#191

Post by kibwen »

qznc wrote: post #78
kibwen wrote: post #42

Earlier quoted context omitted.

Rust doesn't need to stop C++ to be successful. The market for programmers is already large enough to successfully support dozens of programming languages, and that market will only continue to grow. PHP didn't "stop" Perl, Python didn't "stop" PHP, Ruby didn't "stop" Python, and yet all of these languages continue to be enormously successful. Why should we expect a monoculture on the systems side?

I'd say Python did stop Ruby roughly 2006. ;) https://www.google.com/trends/explore?date=all&q=python%20pr...

I'll be sure to tell that to all of my non-techy friends who are attending boot camps for, and subsequently finding jobs in, Ruby rather than Python. :P And I say this as someone who personally prefers Python!

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

#192

Post by AsyncAwait »

dep_b wrote: post #161
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…

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.

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

#193

Post by naasking »

pcwalton wrote: post #176
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…

I keep seeing this latency claim about GC, but it would be trivial to solve with free if it were actually a problem: just add freed objects to a list and incrementally free over time to achieve whatever latency guarantees you wish. The reason why no malloc/free implementations that I'm aware of actually do this is that the latency of freeing isn't a problem in practice.

> The reason why no malloc/free implementations that I'm aware of actually do this is that the latency of freeing isn't a problem in practice.

Partly, and the other part is that it degrades allocation performance for the majority of non-problematic programs, which is what most people actually focus on.

But if we're being fair, latency of tracing GC isn't a problem for most programs either. So latency is largely a red herring, except when it's not, and you had better know when it's not, regardless of whether you're using C/C++/Rust or a runtime with tracing GC.

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

#194

Post by hyperpape »

geodel wrote: post #134
pron wrote: post #51

Earlier quoted context omitted.

What for? If you have the extra RAM and power for a GC, you don't need Rust for safety. HotSpot's next-gen (JIT) compiler is written in Java and is absolutely amazing.

Will that next-gen JIT be enabled by default for Java 9 or 10?

Not by default in 9, but you will be able to run it with a stock version of Hotspot.

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

#195

Post by xpe »

Narann wrote: post #154
leshow wrote: post #9

Rust is great. I've been following it since pre-1.0 and writing code with it for about as long also. It's really come a long way, my favorite language for pretty much anything except web development.

Wow! You've got my attention! I mean, I feel many rust stuff (crates/dev/tools) seems to focus on high performance web so, as a low level guy enjoying bitwise ops and dynarec stuff I was wondering if rust what a good thing for me or if it would be better to stick in C. Can you tell me which kind of project you do in rust, what was your original language and why rust shine compared to your previous language?

(different person here, but I wanted to reply) I'm not sure that I agree as strongly as the first post on this branch, but I really do enjoy Rust. I'm using it for a particular tree-search with pruning computation that caches to RAM and saves to disk. The speed, memory compactness, and correctness are very beneficial. I will admit that getting comfortable with the borrow checker has taken some time, and I still have more to learn!

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

#196

Post by coolsunglasses »

steveklabnik wrote: post #166
hubert123 wrote: post #145

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!

Just to litmus test this, I rebuilt a small Rust project of mine that depends on 41 crates.

Debug build took 15 seconds, release build took 37 seconds. Rebuilds are sub-second.

This is 0.15 nightly.

TBQH, Rust's release builds are already faster than GHC's -O0 builds for me. I'm still bereft a REPL (I live in a REPL), but it's not a deal-breaker.

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

#197

Post by travv0 »

wyldfire wrote: post #127
cbHXBY1D wrote: post #102

Earlier quoted context omitted.

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.

> I often use ripgrep on a copy of the rust repo locally to find answers

I mean, that works, but it's a workaround and not a solution.

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

#198

Post by worik »

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.

"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 make guarantees.

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

#200

Post by IshKebab »

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 solution is the best I've seen so far. Go's multiple return values are pretty good too but I think Rusts's is better.

Post reply on HN