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

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

811–820 of 1001 posts

Re: A Sad Day for Rust

#811

Post by disintegore »

dang wrote: post #810
disintegore wrote: post #70

Earlier quoted context omitted.

A community grows and eventually reaches the point where users cannot recognize who they're interacting with nearly every time, where the submission queue is trailing down too fast for any single reader to process. When that happens, it can no longer function as a cohesive community. It becomes about as personal as a magazine about the very same topic. Furthermore, the incentives to post change due to the higher pote…

> Armchair psychology, coupled with pure distilled condescension. Please edit out name-calling from your comments on HN, as the site guidelines ask: https://news.ycombinator.com/newsguidelines.html Your comment would be fine without the first sentence.

The edit window for that post is sadly over, but I'll be more careful in the future.

Re: A Sad Day for Rust

#812

Post by ori_b »

aidenn0 wrote: post #669
bpt3 wrote: post #661

Earlier quoted context omitted.

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. Therefore, any other supposed obligations only exist…

> You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. There's a word for people who only fulfill their legal obligations: Assholes.

> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who stake their professional reputation on the work of random assholes on the internet.

Re: A Sad Day for Rust

#813

Post by the_af »

solidasparagus wrote: post #698
the_af wrote: post #591

Earlier quoted context omitted.

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal. From https://www.rust-lang.org/ : > "A language empowering everyone to…

> If someone finds this kind of thing "boring", is Rust really for them? Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...

Agreed on all counts: Rust is a tool and you don't have to agree with the tool designers. It's just bizarre to ignore precisely the aspect of the tool that singles it out, the reason it was created to begin with, the one thing this tool is very opinionated about.

You can also write all your Haskell programs with all functions with type IO. You can use a hammer to paint portraits.

Just expect eyebrows to be raised.

Re: A Sad Day for Rust

#814

Post by charonn0 »

Ragnarork wrote: post #95
vunie wrote: post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects? You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it. If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not he…

It all went wrong when the number of users exceeded the number of programmers.

Re: A Sad Day for Rust

#815

Post by [deleted] »

kbenson wrote: post #681
_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate. Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of researc…

[deleted]

Re: A Sad Day for Rust

#816

Post by mumblemumble »

p1esk wrote: post #805
_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

as soon as I saw the large amount of unsafe code, I stopped considering it at all So in that case you wouldn’t use any software written in plain C, right?

At the risk of projection, that comment reads to me as an attempt at playing gotcha.

It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose in a way that you might not want to welcome into your own codebase if you don't have to.

Where unsafe is supposed to be treated as a sort of pinky swear that says, "The compiler couldn't guarantee that this is safe, so I did," that starts to get scary, because any errors will undercut the safety guarantees that the compiler is supposed to be enforcing on your own code. And a large volume of unsafe code implies a large manual verification burden, and a larger volume of code that's easy to accidentally break. And the more of it that should be manually verified there is, the lower the chances that it is actually being manually verified. So it threatens to defeat the ostensible purpose of choosing a language like Rust in the first place.

That's not to say that programming Rust that way is wrong or evil in any objective sense. But it's something that needs to play into a decision on whether to take a dependency on such code. When you link code, you're inviting it into your process space, and you now have to accept responsibility for anything it does while it's in there.

Re: A Sad Day for Rust

#817

Post by the_af »

cosarara wrote: post #676
the_af wrote: post #591

Earlier quoted context omitted.

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal. From https://www.rust-lang.org/ : > "A language empowering everyone to…

> is Rust really for them? Maybe he likes rust because of other things. He had a very successful project with rust, it seems weird to think that rust was not the tool for him.

I don't disagree. But a tool can be successful in adoption and still not be correct from a technical point of view.

"Who cares about correctness or safety?" one could ask. Well, Rust's designers for one. It's why they created the language.

Re: A Sad Day for Rust

#818

Post by dang »

disintegore wrote: post #811
dang wrote: post #810

Earlier quoted context omitted.

> Armchair psychology, coupled with pure distilled condescension. Please edit out name-calling from your comments on HN, as the site guidelines ask: https://news.ycombinator.com/newsguidelines.html Your comment would be fine without the first sentence.

The edit window for that post is sadly over, but I'll be more careful in the future.

If you want to edit it out, I've reopened the comment for editing.

Re: A Sad Day for Rust

#819

Post by kelnos »

strbean wrote: post #656
_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

I have to question your position from a moral standpoint though. If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...

> Obviously the stakes are wildly different

This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.

In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)

Re: A Sad Day for Rust

#820

Post by kelnos »

nindalf wrote: post #729
swayson wrote: post #717

Earlier quoted context omitted.

That is a false equivalence, roller coasters have far more material risk given human lives are at stake.

If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers? Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.

Yes, and you're making the same mistake that you're railing against: if you're going to invoke some sort of moral imperative to do something, you have to examine the risk of what can happen if you do nothing. In the case of something like Heartbleed, yes, the consequences of silence could be quite high. But I just can't see the same argument against remaining silent for this web framework.

It's also a matter of degree and thoroughness. There's a huge difference between "I've found a specific exploitable vulnerability in this security library and here is a proof-of-concept exploit", and "after a cursory look, I see this rust code uses a lot of `unsafe` and I'm uncomfortable with that".

Post reply on HN