A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#581

Post by rakoo » Fri, Jan 17, 2020, 6:26 PM UTC

Touche wrote: post #551

kllrnohj wrote: post #503

Earlier quoted context omitted.

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

Read the license, it frames the project exactly.

The license is to a project's readme what patent claims are to the rest of the patent document: when there is a conflict, it's the one thing both sides can agree on.

However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.

Re: A Sad Day for Rust

#582

Post by mratsim » Fri, Jan 17, 2020, 6:26 PM UTC

lukebitts wrote: post #248

nickbauman wrote: post #209

Earlier quoted context omitted.

When you write "... the Rust project saw Rust as more than just the language. The community and the people mattered." I have to ask why anyone thinks this isn't true for ANY code/stack/dep out there? When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of…

> Rust seems to be being used most by people who are interested in blockchain and crypto Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.

Probably related to the Reddit job ads when you read /r/rust.

That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives.

I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by communities which absolutely cannot compromise on safety and speed (communities referring to both cryptography and blockchain communities as they are distinct).

Disclaimer: I work in blockchain, I implement cryptographic primitives. While I don't use Rust, I do read a lot of Rust code from other blockchain projects or from cryptographers from elliptic curve cryptography to hashing functions.

Re: A Sad Day for Rust

#583

Post by aprdm » Fri, Jan 17, 2020, 6:27 PM UTC

NewsAware wrote: post #361

aprdm wrote: post #337

Earlier quoted context omitted.

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

I worked with a person who happens to have one of the most popular OSS Packages of my industry.

He has a kid and works 8hs a day like all of us... some merge requests are two years old, he doesn't have time for all the feedback / suggestions he receives and just keeps coding in his very limited time because is what he is passionate about... people keep using it.

Re: A Sad Day for Rust

#584

Post by AstralStorm » Fri, Jan 17, 2020, 6:27 PM UTC

rckoepke wrote: post #539

Turing_Machine wrote: post #508

Earlier quoted context omitted.

Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context. Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing eve…

They actually do exactly that. The only goal of Ubuntu is to provide usability. They will care about security to an extent it does not interfere with that goal.

Such as maintainers being overloaded fixing visible issues.

You want a security oriented distribution, you picked the wrong one.

Re: A Sad Day for Rust

#585

Post by _-___________-_ » Fri, Jan 17, 2020, 6:28 PM UTC

munmaek wrote: post #430

_-___________-_ 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…

What do you use now? Warp?

We just use hyper directly, with a small amount of glue code to use serde_json, serde_urlencoded for body parsing and a very simple (and very fast) router of our own creation. This approach also made it very simple for us to introduce std-future/async-await in a gradual way.

Re: A Sad Day for Rust

#586

Post by rakoo » Fri, Jan 17, 2020, 6:29 PM UTC

ambrice wrote: post #531

zzzcpan wrote: post #507

Earlier quoted context omitted.

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages ma…

So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?

I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.

Re: A Sad Day for Rust

#587

Post by lostmyoldone » Fri, Jan 17, 2020, 6:29 PM UTC

AnIdiotOnTheNet wrote: post #193

lallysingh wrote: post #104

Earlier quoted context omitted.

The best justification for this attitude is that it's the most encouraging of open source development. Other attitudes raise the cost of open source development -- considering that it's already a losing proposition (w.r.t. lost time + opportunity) -- and will result in less quality open source software. People just won't put the work in if all they get back is this entitled bullshit.

I feel as though there's a certain developer entitlement that also needs addressing though. Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it. I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't act…

The opinion that the software isn't that good for the problem is cheap to state, and unless the circumstances are exceptional, I would argue it quite reasonable to see it as entitlement.

If someone is terribly dressed according to my taste but brags about how amazing the garb is, I'm not going to tell them how they are wrong unless absolutely necessary because of exceptional circumstances.

Neither does most people who respect others right to their own body, and creativity.

I don't ring up the artists after visiting a gallery to tell them how their art is done, not unless I'm an ass.

Source code is not much different, it is an expression of technical competency, art, taste, and fashion.

If someone asks for feedback, sure, your points are not wrong.

In practicing social dancing, asking if someone wants feedback before giving it generally works out really well. Most people want feedback if you give them the power to choose for themselves, but quite a few really do get hurt if it is unsolicited. There will be some people that get slightly annoyed that you ask, as they prefer more direct approach, but neither they or anyone else get hurt.

Something similar probably works for open source projects too. Engage seriously for a bit, and only then ask if your input on your particular issues would be interesting to the other party.

Re: A Sad Day for Rust

#588

Post by aprdm » Fri, Jan 17, 2020, 6:29 PM UTC

iudqnolq wrote: post #537

NewsAware wrote: post #361

Earlier quoted context omitted.

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

I thought basic etiquette was issue to discuss before PR? Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better". Is that wrong?

For what its worth I agree with you

Re: A Sad Day for Rust

#589

Post by topspin » Fri, Jan 17, 2020, 6:30 PM UTC

Fork. That's the answer. It's not friendly or nice or kind or whatever, but that's the answer. Rust and its ecosystem of people and their work are not magical; there are and will be difficult people and yes, sometimes the correct answer is to shun them by forking the work and leaving the problem children behind. It is impossible to avoid this when building a complete language paradigm involving so many people.

Nikokay isn't the problem. His indifference to soundness concerns is inevitable; Rust pragmatically doesn't preclude reckless programming and that's a good thing except that some people will, in fact, be reckless. The actual problem is the naive expectation that Nikokay's indifference and recklessness can somehow be fixed by the 'community.' It clearly can't. The 'community' needs to sack up and fork stuff until it's happy with the work.

Re: A Sad Day for Rust

#590

Post by Ntrails » Fri, Jan 17, 2020, 6:30 PM UTC

ambrice wrote: post #531

zzzcpan wrote: post #507

Earlier quoted context omitted.

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages ma…

So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?

You should accept that you are responsible for all the code you run in production, whoever happened to write it. Whether you feel you are more likely to write bug free code than anyone else is your call.