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

451–460 of 511 posts

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

#451

Post by wtetzner »

webkike wrote: post #132
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.

Regardless there is no overhead for lifetimes. It is a data flow analysis problem used solely to verify correctness of the code.

I think they're referring the the calls to "free" that are automatically injected.

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

#452

Post by braveo »

MaulingMonkey wrote: post #322
braveo wrote: post #261

Earlier quoted context omitted.

Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.

> It doesn't really matter if they both end up at the same place, which is safe software. I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) SaferCPlusPlus's goals are noble, but approa…

> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.)

That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good warnings that you can treat as errors, and coupled with good external tools it isn't clear that rust is significantly safer than C++.

The scary part of it all is how many rust users seem to think that it is a given when even the rust standard vec container has unsafe code in it.

I personally think that if rust is shown to statistically decrease the security/error rate on large projects, it's going to be with the use of 3rd party tools, not the specific semantics of the language. I'm of the opinion that the beauty of the unsafe block isn't in any inherent "safety", as much as it is giving more semantics for 3rd party tools to analyze.

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

#453

Post by quotemstr »

steveklabnik wrote: post #450
quotemstr wrote: post #326

Earlier quoted context omitted.

Tell me more about how std::string is unreasonable.

Are you talking about Rust's or C++'s? Name conflict :) In Rust, std::string::String is not a "value type", and by that, I mean it's not Copy.

C++'s.

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

#454

Post by jokoon »

pcwalton wrote: post #448
jokoon wrote: post #147

Earlier quoted context omitted.

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…

Do you have a proposal to achieve Rust's goals in a way that's easier to learn?

syntax

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

#455

Post by jstimpfle »

lmm wrote: post #430
jstimpfle wrote: post #177

Earlier quoted context omitted.

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…

The type corsets of ML-family languages have been the best design experience I've ever had. My programming intuition has got a lot better by using them; it's much easier to spot that there's a subtle issue with the design if it shows up as friction in the types. Even in something like Python the lessons apply, though I have to devote a lot more attention to it since I can't rely on the compiler to show me. Just my su…

Maybe I am not smart enough, but it's never clear to me what things should be cast in type. Type the one invariant, can't type the other - and the other way around. The choice seems often arbitrary. But it has a huge influence on the overall design.

Sum types are a major headache. Is there a good rule for when to use a sum type vs distinct types? The expression problem is very practically relevant to me. Also the typical flat vs hierarchial data storage wisdom applies: Trees and hierarchies are very much encouraged by HM type systems, but the choice of what gets to be parent and what gets the child is arbitrary and often turns out super limiting further down the line. Similarly, there's the choice of what to include in a hierarchy and what to put in a separate one.

Tables on the other hand, supported by light usage of manually coded lookup tables, have been the real game changer for me. When I'm back in a normal imperative language I can be so naturally productive and write efficient programs without relying on black compiler magic. I don't see how most of the invariants in my programs could ever be codified in a practical type system. They are so relational - they involve variables with very diverse lifetimes and expressions depending on dynamic values.

In the end, I feel writing assertions is just much better for me, because I can be somewhat sure in a few tries that my invariants hold, in the same language that I use for coding, and having the same values available. Meanwhile I would waste hours trying to codify a small fraction of them in an HM type system.

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

#456

Post by tatterdemalion »

braveo wrote: post #452
MaulingMonkey wrote: post #322

Earlier quoted context omitted.

> It doesn't really matter if they both end up at the same place, which is safe software. I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) SaferCPlusPlus's goals are noble, but approa…

> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good…

With no `unsafe` blocks, show me how you could use the `Vec` type to break Rust's memory safety guarantees.

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

#457

Post by rweichler »

burntsushi wrote: post #221
rweichler wrote: post #202

Earlier quoted context omitted.

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

As the author of ripgrep, I can assure you, the burden on me as the programmer was lifted quite a bit! I probably wouldn't have been able to build it otherwise. (Not because it's physically impossible, but because it would have taken too much time.) It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: htt…

Oh wow, The creator in the "flesh"! Thanks for replying to me.

Hypothetical scenario: Let's say you're writing an experimental tool that doesn't exist anywhere else. You don't care about security, you don't care about speed. You just want it to exist so you can see what it does and possibly iterate on the idea if it ends up working out. Would Rust still be feasible?

From my impression of it, you would need to take care of a lot of corner cases and such (which don't exist in other languages) that may slow you down in the short run. I'd imagine those corner cases would be extremely helpful in the long run if you want to squeeze some extra performance out of it (or avoid technical debt). But from the perspective of "figuring out what's possible" I feel like Rust would get in the way a lot.

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

#458

Post by staticassertion »

user5994461 wrote: post #293
wyldfire wrote: post #108

Earlier quoted context omitted.

They would explain Rust's relative youth and corresponding growth opportunity. ;)

Ada was designed for system programming and, at a time, was also a young language with a huge opportunity for growth ;)

To compare Ada's history to Rust's is silly. Even if the languages have a common goal of safety, the projects themselves are fundamentally different in many many ways. One of which is the fact that Ada was designed by the DoD for the DoD, and required a verified compiler, etc etc etc.

They're totally different projects, even if the languages have a small number of shared goals.

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

#460

Post by staticassertion »

enqk wrote: post #184
__david__ wrote: post #117

Earlier quoted context omitted.

> However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets. Sure it can. It actively prevents certain type of errors (buffer overflows, integer overflows), which are prime security exploits. Less exploits == more security.

My standpoint is that: - Less exploits is an improvement in frequency - More security is a question of limiting impact

I don't think I want to get into what is or is not security, but what I will say is that rust's security does not interfere with safety net features, like sandboxing.

I've found that sandboxing rust is quite easy, as easy as C or C++. I find it much easier than Java/ Python, which have runtimes that can often make things difficult (you certainly would not want to use seccomp in either).

Take a look at DropBox's Brotli - it's a great example of this. It makes use of seccomp, but seccomp is not available on all platforms, so it also relies on rust's safety.

Post reply on HN