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

541–550 of 1001 posts

Re: A Sad Day for Rust

#541

Post by lanstin »

yazaddaruvala wrote: post #421
iovrthoughtthis wrote: post #402

Earlier quoted context omitted.

I’m not so certain emotion and logic are so fundamentally separate you know. Perhaps logic is just our way of explaining our otherwise unexplainable decision making systems.

My belief is that intuition and emotion are just complex sets of logic that we haven’t understood yet. Put in the time and focus, and one day it will just click.

I think the emotions and really the whole operation of the mental states is reasonable, but not internally logical. They arise in predictable patterns from experiences and so on, but they can very easily override logic. To understand your emotions, you have to see and admit you aren't the nice logical person you might have expected.

Re: A Sad Day for Rust

#542

Post by logophobia »

Turing_Machine wrote: post #508
logophobia wrote: post #475

Earlier quoted context omitted.

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

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

I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.

Re: A Sad Day for Rust

#543

Post by rectang »

juped wrote: post #527
rectang wrote: post #410

Earlier quoted context omitted.

> Maybe I'll even use a non-free license just to reinforce my "you take what you can get" policy. Consider CC0 instead. As a veteran open source contributor, I totally understand that dealing with open source communities has a huge cost to go with the huge benefit. Even just vetting patches can be a pain when you care about security and architecture and don't want to spend time endlessly explaining your choices. CC0…

Please don't blindly attempt dedication of your works to the public domain based on this comment.

What is your objection? Do we have a disagreement about licensing, for instance because you'd advocate a copyleft license instead? Or do you disagree with the notion that open source contributors should have the option of opting out of social coding?

Certainly I would expect amyjess and anyone else reading to exercise due skepticism and perform their own research and I respect them enough to expect that they will "consider" my suggestion rather than "blindly" follow it.

Re: A Sad Day for Rust

#544

Post by dodobirdlord »

logophobia wrote: post #475
BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, 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. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

That is why the Apache license has a responsibility disclaimer, that to the extent allowable under law the work is offered with no warranty and no guarantees, not even of correctness or usability for any particularly purpose. Words still mean things, even after we get so used to copying and pasting licenses that we forget that they mean something. If you expect a project maintainer to take responsibility, ask them to use a license where they take responsibility.

Re: A Sad Day for Rust

#545

Post by mroche »

aspaceman wrote: post #423
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…

This isn’t true at all. Many projects even say “we won’t accept PRs” in their README. When the code is being used internally at Microsoft, it makes even more sense they wouldn’t take PRs.

There's been a request going for several years now to disable Pull Requests on GitHub[0]. They allow project maintainers to disable Issues, they should also be allowed to disable PRs rather than use automation to close any opened PR. Other SCM products (e.g. GitLab) offer the ability to make PRs available only to project members, or disable them completely.

[0] https://github.com/dear-github/dear-github/issues/84

Re: A Sad Day for Rust

#546

Post by lanstin »

BowBun wrote: post #343
dbcfd wrote: post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, 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. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

Seriously, you can just fork the source repo and do what ever you want with them, and pull from your repo.

Re: A Sad Day for Rust

#547

Post by dependenttypes »

I would feel sad for the creator but after reading more about this it feels like they were clearly acting with malicious intentions, such as removing a bug report from months ago because someone mentioned it in an article, or being rude to contributors.

I do not believe that anyone is entitled to free features/bugfixes/etc on foss projects but apparently this is not what happened in this case.

Re: A Sad Day for Rust

#548

Post by roywiggins »

tssva wrote: post #325
steveklabnik wrote: post #139

Earlier quoted context omitted.

Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."

Depending on the context that doesn't seem to be "far, far over the line." Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.

I believe the Rust community has been trying to draw a line somewhat short of where systemd discourse ended up.

Re: A Sad Day for Rust

#549

Post by akamaka »

Animats wrote: post #518

I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in th…

I’m replying to your message using software written in C, so do you think that it might be a little bit unfair to call it “broken”?

I suppose I’d agree if you’re making a general argument that most of the software we use is broken to some degree, but it has an entirely different meaning to directly tell someone “Your library is broken”.

Re: A Sad Day for Rust

#550

Post by wolrah »

amyjess wrote: post #327
pjc50 wrote: post #273

Earlier quoted context omitted.

Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

Python is my language of choice, so posting projects means publishing the source code.

> Python is my language of choice, so posting projects means publishing the source code.

Technically you could just post the .pyc bytecode as long as you didn't care about it working on anything but CPython and compatible implementations.

Post reply on HN