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

501–510 of 511 posts

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

#501

Post by [deleted] »

shandor wrote: post #442
erikpukinskis wrote: post #351

Earlier quoted context omitted.

> because everyone already has their 20 year old [C] codebases It's comments like these that remind me how exclusionary the software world is. Your definition of "everybody" is such a tiny number of people. But that's who you have in mind when you are constructing the world around you each day.

Well, one might notice "everybody" has to be a rhetoric exaggeration, since there's absolutely no way even remotely close to "everybody" would have any codebase at all whatsoever, not to talk about 20 year old legacy. Right? Second, I was responding to a comment talking about "existing, critical, real time applications". Of which a huge number of cases do have existing, very old legacy codebases. Third, I fail to see…

[deleted]

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

#502

Post by rweichler »

burntsushi wrote: post #476
rweichler wrote: post #457

Earlier quoted context omitted.

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

Good question! The inherent problem with asking me that is that I've been writing Rust continuously for over 2.5 years by now. I live and breathe it. It comes as naturally to me as Go or Python does at this point (which I've been writing continuously for even longer). I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrin…

Thanks for the insight! I may give Rust another shot at some point. Interoperating it with Lua may be fun.

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

#503

Post by lmm »

z3t4 wrote: post #463
lmm wrote: post #432

Earlier quoted context omitted.

> There are advantages to GC, even Rust has runtime GC. If you want GC there are any number of good languages to pick with it (e.g. OCaml). > Also when something goes wrong with types in JavaScript the worst case scenario is "2"+2 turns into "22" witch is easy to avoid, compared to a silent overwrite/overflow. It's memory-safe but it's not safe. What if an error like that happens in your permission-checking code? I a…

The problem here is that + is used for both addition and concatenation. Most of the time you know what you are doing though ( smile ) and string is the default. When I started out with JavaScript I used -- (minus minus) for addition just to be safe. If you where to compare "22" == 22 ? it would be true, so the type doesn't really matter. If you want to do arithmetics on a string, no problem! Even null behaves like a…

> Someone once told me that JavaScript is a lot like assembly because you are so free, there is no one telling you "No, you shouldn't do it that way" like in Rust.

Um, yeah. I think that's a fair comparison. And anyone who's had to debug or maintain a large system written in assembly/javascript knows why that's a bad idea.

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

#504

Post by lmm »

jstimpfle wrote: post #455
lmm wrote: post #430

Earlier quoted context omitted.

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

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

I find it best to let confidence guide me. If I'm not confident something's right, that's usually a sign I didn't type it enough. If I think I know it already, then it doesn't need more types. It affects the design but it should affect the design, I would say; decisions about which invariants are important are design decisions.

> Is there a good rule for when to use a sum type vs distinct types?

If at some point you have a value that you know (and care) is one particular, well, type, make it a real type. If you only ever have values that could be one or the other and it doesn't matter which they are (or the section where it matters can be reasonably confined to a match block) then a sum type.

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

I find this is much less true in an immutable-by-default language. E.g. in the standard circle/ellipse example it becomes completely obvious which is the parent and which is the child.

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

Heh, this is the opposite of my experience. I find tables always confuse me, and are usually a sign that my model needs to have an intermediate entity - like the experience described in http://wiki.c2.com/?WhatIsAnAdvancer

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

#505

Post by braveo »

leshow wrote: post #497
braveo wrote: post #478

Earlier quoted context omitted.

> The fundamental fact remains that the compilers do not warn about the major problem of handling dangling pointers I'm going to quote myself, emphasis mine. "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." [snip] "C++ compilers tend to give pretty good warnings that you can treat as errors, and __coupled with good external tools__…

quoting pcwalton up above: "I don't care if the software is verified via libraries or compilers. The problem is that C++ verifiers don't work."

right, I too can make assertions with no evidence to back them up.

If that's really your bar, then we don't have much more to discuss.

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

#506

Post by braveo »

dbaupp wrote: post #500
braveo wrote: post #483

Earlier quoted context omitted.

Hey, you're right, getting memory usage correct doesn't affect safety at all. good day.

Reading an array out of bounds is definitely unlikely to be correct/be a security vulnerability. Memory safety is absolutely a prerequisite for any other sort of safety one might want.

We agree on that, my point is that C++ does it via libraries, Rust does it by hiding unsafe blocks behind interfaces (aka libraries).

Time will tell which approach is ultimately superior (if either one of them is actually better), but until the it isn't clear that the Rust approach is statistically better than the C++ approach.

Ultimately the advantage Rust has is the ability to possibly provide better 3rd party tooling that will enable developers to make the right decisions more often than C++ does. Consider a tool that runs on code checkin that spits out a report of all sites where code that manipulates state that could affect an unsafe block was changed/written so that developers could then have a very focused peer review of the code to ensure the safe code doesn't put the state in such a spot that it causes problems.

I think in this way Rust may eventually be shown to be better than C++, but then again, maybe not.

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

#507

Post by burntsushi »

braveo wrote: post #506
dbaupp wrote: post #500

Earlier quoted context omitted.

Reading an array out of bounds is definitely unlikely to be correct/be a security vulnerability. Memory safety is absolutely a prerequisite for any other sort of safety one might want.

We agree on that, my point is that C++ does it via libraries, Rust does it by hiding unsafe blocks behind interfaces (aka libraries). Time will tell which approach is ultimately superior (if either one of them is actually better), but until the it isn't clear that the Rust approach is statistically better than the C++ approach. Ultimately the advantage Rust has is the ability to possibly provide better 3rd party tool…

> We agree on that, my point is that C++ does it via libraries, Rust does it by hiding unsafe blocks behind interfaces (aka libraries).

That's a false equivalency and completely ignores the fact that C++ is one giant `unsafe` block.

> but until the it isn't clear that the Rust approach is statistically better than the C++ approach

Could you please explain what kind of evidence would convince you?

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

#508

Post by nercht12 »

coolsunglasses wrote: post #183
nercht12 wrote: post #88

Earlier quoted context omitted.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

Cinch, like cinching up a belt. Synch is short for synchronization.

Oops. Thanks.

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

#509

Post by nercht12 »

solidsnack9000 wrote: post #409
nercht12 wrote: post #88

Earlier quoted context omitted.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

> I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. > Remember, with game production, it's about time-to-market, not about perfect code. In a way you are over-selling Rust, because it doesn't offer perfect code! I'm not sure why Mozilla would pay to build it if that's what it was about. W…

To be clear, I didn't say Rust offered perfect code. But supposedly better code comes from Rust, as you're arguing.

While Rust as a language isn't more complex, the paradigms are different. Games often have trees and lists, which are a real pain in Rust. To do things right in Rust requires learning new ways of doing things - not something game devs want to spend time on. They've been working with the same horse for years, so they keep riding it.

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

#510

Post by braveo »

burntsushi wrote: post #507
braveo wrote: post #506

Earlier quoted context omitted.

We agree on that, my point is that C++ does it via libraries, Rust does it by hiding unsafe blocks behind interfaces (aka libraries). Time will tell which approach is ultimately superior (if either one of them is actually better), but until the it isn't clear that the Rust approach is statistically better than the C++ approach. Ultimately the advantage Rust has is the ability to possibly provide better 3rd party tool…

> We agree on that, my point is that C++ does it via libraries, Rust does it by hiding unsafe blocks behind interfaces (aka libraries). That's a false equivalency and completely ignores the fact that C++ is one giant `unsafe` block. > but until the it isn't clear that the Rust approach is statistically better than the C++ approach Could you please explain what kind of evidence would convince you?

> That's a false equivalency and completely ignores the fact that C++ is one giant `unsafe` block.

This is exactly what I meant when I said rust people miss the forest for the trees.

> Could you please explain what kind of evidence would convince you?

you quoted me explaining what I would need.

Post reply on HN