Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

451–460 of 474 posts

Re: Rust is mostly safety

#451

The memory safety of Rust is over consumed. 1. several small languages also introduce the type system to try to solve the memory safety problem. But all of them are less famous. Because there are many reasons that makes a language being accepted massively from other tons. 2. in many cases, it is not hard to do manual memory management. There are many great software done with manual memory management. Although I admit…

>Who like to read the following function declaration?(just borrowed as example):

> fn foo(x: &'a str, y: &'b str) -> &'a str

Anybody who cares about the validity of pointers would like to read that. It very explicitly tells you what must be true of the arguments for them to be valid and for how long the result will be valid.

In general, you seem to be over-valuing conciseness. If you think conciseness is more important than memory safety, feel free to not use Rust. But frankly, it is trivial to make a language more concise. That's not a hard problem whatsoever.

Re: Rust is mostly safety

#452
post #432

Earlier quoted context omitted.

This comment crossed into incivility. Please remain civil when commenting here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=13282431 and marked it off-topic.

I think you have an inconsistent threshold for civility. The post I replied to had it's fair share of snarkiness, insincerity, exaggerations, and patronizing.

I don't read it that way, but even if you're right, you need to follow the rules regardless.

Re: Rust is mostly safety

#453
post #452

Earlier quoted context omitted.

I think you have an inconsistent threshold for civility. The post I replied to had it's fair share of snarkiness, insincerity, exaggerations, and patronizing.

I don't read it that way, but even if you're right, you need to follow the rules regardless.

Not a very civil tone. Just go ahead and ban my IP or something... I'm not particularly interested in appeasing you.

Re: Rust is mostly safety

#454

Earlier quoted context omitted.

It's a specifications issues, not a programming issues.

I disagree. The programmer is the expert in types, so it is the programmers duty to ensure that the possible values stored in a variable of a given type are compatible with the type selected. Particularly when it comes to these sort of critical applications. Programmers blindly following specs put together by people who have no claim to expertise in these matters without questioning the assumptions behind the spec is…

The software component in question was implemented according to its specification, and never failed in the environment for which it was developed, the Ariane 4.

The decision to re-use the component as-is in the Ariane 5 without sufficiently investigating the consequences of the higher horizontal velocities that it is subject to compared to the Ariane 4 cannot so obviously be blamed on the programmer that implemented it years before in a different context.

Re: Rust is mostly safety

#455

Earlier quoted context omitted.

I disagree. The programmer is the expert in types, so it is the programmers duty to ensure that the possible values stored in a variable of a given type are compatible with the type selected. Particularly when it comes to these sort of critical applications. Programmers blindly following specs put together by people who have no claim to expertise in these matters without questioning the assumptions behind the spec is…

The software component in question was implemented according to its specification, and never failed in the environment for which it was developed, the Ariane 4. The decision to re-use the component as-is in the Ariane 5 without sufficiently investigating the consequences of the higher horizontal velocities that it is subject to compared to the Ariane 4 cannot so obviously be blamed on the programmer that implemented…

Thanks for the extra context, and alternate interpretation. You seem like you might know this story better than the writer of the referenced article, but you and the author seem to be making contradictory causal claims. I hold to my conclusion if the author's story is taken as authoritative. If yours is more authoritative, then it sounds like your conclusion is better.

I kind of took the story as an allegory when writing my comment. The article is quite vague about the details of the situation. And for all I know, it IS programmers that write specs for this European Space Agency unmanned rocket project. But the way the story is told aligns with a more universal experience of programmers blaming specs for the failings of programs, even when they should have recognized that the program was misspecified before implementing it. I ran with that interpretation because it was illustrative of something important, but it is not particularly surprising to me that the details are being questioned. The article was never a rock solid account.

Re: Rust is mostly safety

#456

Earlier quoted context omitted.

Just because some people have a different opinion than you, doesn't mean it is due to fallacious reasoning. Ultimately, it seems to come down to rust haters who have a sunken cost fallacy - I spent years writing bad code in bad lanaguages, so I don't want to give that up to do things better.

Please be more patient :) Flamewars will not help us, definitely. I'm nobody to criticize your way to communicate, but for the sake of Rust community reputation - please let's avoid "Rust vs X" wars.

Please be more patient :) Replying to posts you didn't read will not help us, definitely.

Re: Rust is mostly safety

#457

Earlier quoted context omitted.

Seeing that people keep testifying to the fact that the borrow cHecker gives them problems, I wouldn't say it's just a meme. Its easy and tempting to imagine problem points disappearing over time, but realistically, some portion of people will always run into it, because it's unique and fundamentally a bit complex. It's better to spread that message, that running into borrowing problems is a common, real, yet tempora…

I would say that this is a common message, to a degree. What I commonly see people expressing about Rust is that it took them a while to internalize the borrow checker, possibly a few weeks, and where before that point it was painful to work with to some degree, afterwards it was a boon as it helped them more quickly spot problems and forced them to consider the problem more closely before committing to code that mig…

I'm inclined to agree. It took me a week or two of daily usage to finally "get used" to the borrow checker. It's a bit of a paradigm shift, to be sure, but it's not insurmountable. In fact, I think learning Rust has made even my C code better, because now I'm in the habit of thinking thoroughly about ownership and the like, which is something that I did to an extent before (because you have to to write robust software without a GC), but it was never explicit and I never would've been able to articulate the rules like I can now.

That said, I still occasionally have problems where I feel like I'm doing something "dirty" or "hacky" just to satisfy the borrow checker. It's easy to program yourself into a corner and then find yourself calling `clone()` (the situation, I've been told, has gotten much better in recent releases with improvements to the borrow checker, but alas I haven't had a chance to play much with Rust in nearly a year).

Another thing that I still find difficult is dealing with multiple lifetimes in structs, to the point that I usually just say "to hell with it" and wrap everything in an `Rc`. And sometimes there's simply no safe way (afaict) to do some mutation that I want to do without risking a panic at runtime (typically involving a mutable borrow and a recursive call), which leads to a deep re-thinking of some algorithm I'm trying to implement. That's not Rust's fault, though—it's a real, theoretical problem that arises in the face of mutation. In time, I'm sure there will be well-understood patterns for handling such cases.

Re: Rust is mostly safety

#458
post #433

Who are you fooling? I'm well aware of the author's history with Rust. Sorry if I confused you. Do you support his "experienced" view that all of the C or C++ programmers who don't put a particularly high value on safety are either ignorant or negligent? Now's your chance - take a stand and support your team mate! > Can you give me an example of a comment in this thread that you find to be from a pretentious beginner…

You've repeatedly become uncivil in this thread. That's against the rules here. We ban accounts that do this, so please post civilly and substantively, or not at all. We detached this comment from https://news.ycombinator.com/item?id=13282695 and marked it off-topic.

please take your life somewhere else.

Re: Rust is mostly safety

#459
post #432

> Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances. > Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Are we looking at the same page? Swift wins the first 3, ties on the next…

This comment crossed into incivility. Please remain civil when commenting here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=13282431 and marked it off-topic.

please take your life somewhere else.

Re: Rust is mostly safety

#460
post #309
post #305

Earlier quoted context omitted.

I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours. With that said, can you recommend a good source to really understand best practices and patterns for ownership…

Alas, I think a week is too short to give Rust. Go will get you more pay-off in the short term, but as you internalise the rules of Rust you'll really start to reap the benefits. Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.

> Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.

How about http://rust-lang.github.io/book/ ?

Post reply on HN