Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RustBelt: securing the foundations of the Rust programming language

dl.acm.org

Post reply on HN
Print view View original

61–70 of 109 posts

Re: RustBelt: securing the foundations of the Rust programming language

#61

Post by namelost »

pcwalton wrote: post #33
nukeop wrote: post #8

I have recently performed a relatively simple development by using programming languages on which I had low-to-to-no experience: Perl (low), Ruby (no), Rust (no) and Go (no). Note that I am quite adaptable on the programming language front and that this small experiment was precisely meant to showcase these adaptability skills. Rust was, by far, the most difficult-to-learn, difficult-to-research, counter-intuitive, u…

> The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one. Programs written in Rust are empirically safer than programs written in C or C++. > The higher the freedom, the better the results delivered by a sensible/knowledgeable person. If that were true, then C and C++ code would be safer and more se…

> > The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one

> Programs written in Rust are empirically safer than programs written in C or C++.

But Rust defines safety as being safe from the kinds of errors that the Rust compiler is capable of making one safe from (buffer overflows, race conditions, undefined behaviour, etc).

If one if distracted by trying to satisfy the borrow checker, they might overlook a logical error. People have limited concentration, patience and perseverance and usually have to work to deadlines.

Rust is great for writing high-performance code, or code that needs to be parallelised within a single process. However if performance is not a concern then a statically typed language with a GC is usually a better choice.

Re: RustBelt: securing the foundations of the Rust programming language

#62

Post by carapace »

quotheth wrote: post #55
carapace wrote: post #50

> Rust is a new systems programming language that promises to overcome the seemingly fundamental tradeoff between high-level safety guarantees and low-level control over resource management. Unfortunately, none of Rust’s safety claims have been formally proven, and there is good reason to question whether they actually hold. Aw, c'mon!? Rust is Sudoku for super-smarties. - - - - I'm going to "double-down" on that: Ru…

I work for a company with a massive rust codebase. Rust is very much about building production code. What is 'good production code' ? * Few errors * Readable, well documented * Testable, has tests, has testing tools like quickcheck, fuzzing, etc * Meets performance constraints Rust hits those better than any language I've used. The downside is, oh gosh, you'll have to actually learn a programming language that isn't…

> I work for a company with a massive rust codebase. Rust is very much about building production code.

Okay, thank you, I feel a little better hearing that.

Re: RustBelt: securing the foundations of the Rust programming language

#63

Post by catach »

nukeop wrote: post #41
pcwalton wrote: post #33

Earlier quoted context omitted.

> The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one. Programs written in Rust are empirically safer than programs written in C or C++. > The higher the freedom, the better the results delivered by a sensible/knowledgeable person. If that were true, then C and C++ code would be safer and more se…

I don't see too many job offers for Rust developers, I see plenty for C and C++ though.

The youth of the language should be a reasonable predictor of that difference, alone.

It may indeed turn out that the way Rust's learning curve is front-loaded will prevent it from breaking into the mainstream, but that's a separate issue from developers deciding it's unsuitable for work after they learn it.

Re: RustBelt: securing the foundations of the Rust programming language

#64

Post by dmix »

tom_mellior wrote: post #46
dmix wrote: post #22

Earlier quoted context omitted.

One thing about formal verification, and a lesser extent automated testing, is that you often end up spending the majority of the time adapting the program or language to work with verification rather than actually solving a real-world problem or fixing a real bug. His third comment fits this category well. The problem set he describes was that the code is designed in a way that's ill suited for formal verification.…

> But he never mentions any other benefits or justification for changing how it works. I read "it lets me write a program that has a data race", accompanied by a program that has a data race, as saying that the bug is that a language feature meant to provide mutual exclusion does not provide mutual exclusion. In a language one of whose main selling points is "you always get mutual exclusion". How is this not a bug? T…

I was specifically referring to the 3rd comment on the Github issues page, not the first comment which mention a race condition which the eventual commit addressed

> His third comment fits this category well.

And even then I was only talking about the language he used, aka the justifications and rationale he proposed, which seemed entirely around being difficult to verify formally, rather than mentioning any real hypothetical 'bug', security flaw, or architectural downside.

Re: RustBelt: securing the foundations of the Rust programming language

#65

Post by dbaupp »

namelost wrote: post #61
pcwalton wrote: post #33

Earlier quoted context omitted.

> The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one. Programs written in Rust are empirically safer than programs written in C or C++. > The higher the freedom, the better the results delivered by a sensible/knowledgeable person. If that were true, then C and C++ code would be safer and more se…

> > The most ironic part is that so many restrictions and problems are likely to provoke people to rely on whatever option happens to work, which might not be the best/safest one > Programs written in Rust are empirically safer than programs written in C or C++. But Rust defines safety as being safe from the kinds of errors that the Rust compiler is capable of making one safe from (buffer overflows, race conditions,…

In this case, safer == memory safety (which is not a Rust-specific thing), not general forms of correctness, and the comparison in the original comment is to C and C++, not statically typed languages with a GC.

Re: RustBelt: securing the foundations of the Rust programming language

#66

Post by sifoo »

bvinc wrote: post #12
nukeop wrote: post #8

I have recently performed a relatively simple development by using programming languages on which I had low-to-to-no experience: Perl (low), Ruby (no), Rust (no) and Go (no). Note that I am quite adaptable on the programming language front and that this small experiment was precisely meant to showcase these adaptability skills. Rust was, by far, the most difficult-to-learn, difficult-to-research, counter-intuitive, u…

> The higher the freedom, the better the results delivered by a sensible/knowledgeable person. Experience has shown this hypothesis to be false, especially concerning low level systems programming languages and security issues.

Until we have as much code written in Rust as is currently implemented in C, experience hasn't shown anything. The same claims and promises have been made for C++ in relation to vanilla C for ages, and it's just not true. An experienced C coder (which arguably takes longer to achieve) will perform as good as a C++ coder of equal skill level. All they do is trade complexity and convenience for simplicity and flexibility; it's a matter of preference, not life and death.

Re: RustBelt: securing the foundations of the Rust programming language

#67

Post by sifoo »

algesten wrote: post #44
nukeop wrote: post #8

I have recently performed a relatively simple development by using programming languages on which I had low-to-to-no experience: Perl (low), Ruby (no), Rust (no) and Go (no). Note that I am quite adaptable on the programming language front and that this small experiment was precisely meant to showcase these adaptability skills. Rust was, by far, the most difficult-to-learn, difficult-to-research, counter-intuitive, u…

I'm sorry you found Rust hard, but it really is a world apart from Perl. I started learning programming using assembly (Motorola 68k), and then went a different professional route (via Java and Javascript). Rust to me is back to basics . There is a stack, and there is a heap. Many languages mask this from you, but notably C/C++ doesn't, and although it's a notch up in complexity from Perl, the control you get over th…

And not everyone who needs/wants that is going to prefer Rust's complexity and rigidness to the simplicity and flexibility of C, or the even more complex yet more flexible C++. It's preferences, priorities; not black or white; no one has any right to force anyone to do anything. As long as humans are in the loop we're going to have bugs, what kinds of bugs will depend on priorities.

Re: RustBelt: securing the foundations of the Rust programming language

#68

Post by steveklabnik »

dawg wrote: post #59
steveklabnik wrote: post #47

Earlier quoted context omitted.

You can, but there is a big difference: betterC is a subset of D, whereas unsafe Rust is a superset of safe Rust. That is, when you use unsafe, you don't lose any language features. When you drop into betterC, you do lose a bunch of stuff from D.

You don't have to restrict yourself to betterC to use manual memory management. BetterC is mainly targetted at embedded programming and to port components of existing C applications. Malloc vs. GC vs. stdx-allocator is a separate topic, though betterC doesn't link with the GC by default.

Yes, thanks. Last I checked, you still lose features if you use manual memory management, betterC or no. Has this changed recently?

Re: RustBelt: securing the foundations of the Rust programming language

#69

Post by sifoo »

ktpsns wrote: post #25

By the way, this is a project funded by the European Union. It got 2 Million EUR by the European Research Council ( https://cordis.europa.eu/project/rcn/200802_en.html ). It is only one of the many projects which give back a lot to the open source community. Thank you, EU!

I'm not quite as enthusiastic about their choice of funding target. There are plenty of other worthy languages and tools out there that could use that money better in my mind. It's the C++/Java thing all over again, but stepped up several notches; to the point where it's creeping me out since I can't even mention C online without being attacked by the Rust Brigade; and they just don't give up, it's like one of those shitty zombie movies where you have squirting body fluids and jaws chopping at you from every angle. I don't think they need any more money; more like therapy, chill pills and rooms with soft walls/locked doors for a while.
Post reply on HN