A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#941

Post by jeddy3 » Sat, Jan 18, 2020, 6:49 AM UTC

steveklabnik wrote: post #30

spamizbad wrote: post #25

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

> Forking is extremely aggressive

We are already WAY past that line, just because people don't fork

> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

So DON'T run a project. Fork it, fix your problems and be done with it.

This seems to be at the core of the disagreements in this thread, one argument being that you shouldn't be expected to maintain a community project just because you put code on the internet.

Expecting that will lead to less open sourced code, which is bad IMHO.

Lastly, your last argument argument reads a little bit as "Not everybody has the desire or time to run a project, so what they want is somebody else to do it"

I might be reading in to much into it though. This thread has a fair amount of pronounced entitlement.

Re: A Sad Day for Rust

#942

Post by oaiey » Sat, Jan 18, 2020, 7:02 AM UTC

Ygg2 wrote: post #922

oaiey wrote: post #675

Earlier quoted context omitted.

The same "stupid" benchmark site let to dramatical improved .NET Core performance , re-engineered the .NET Server stack and even changed the C# language on the way. I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform. PS: just pointing out what the page achieved somewhere else. The discussion about the mainta…

That might be true for Dotnet. But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage. I think the benchmarks are flawed, since they don't account for such "optimizations".

The benchmark is very smart in that sense. It has multiple stages (e.g. plaintext, db access,...). It proves with each stage deeper into your stack. You can disable there parts of your stack (e.g. middlewares, views, controllers, ...) and just operate on low level http request response pairs. And there you can hardcode on top then (as the application). The stages of the benchmark are optimized for testing individual disciplines like the connection and memory management of the low level http server and parser.

In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.

Re: A Sad Day for Rust

#943

Post by aganame » Sat, Jan 18, 2020, 7:17 AM UTC

A community this large can easily deal with a loss of technical talent. It cannot easily deal with toxicity. Therefore, it seems like a good thing actix and its developer are leaving.

Also, a fascinating Trumpian "both sides have good people" -defense play.

Re: A Sad Day for Rust

#944

Post by anon463637 » Sat, Jan 18, 2020, 7:36 AM UTC

There's a tendency for masses of people to eagerly follow strongly-opinionated people. I think such qualities are a big warning sign, especially if they're dramatic, engage in all-or-nothing thinking, unconvinced by evidence and/or put their ego / being "right" ahead of everything and everyone else. Furthermore, there's a tendency for people to get emotionally-attached to "their baby/pet" project and reject anything that doesn't fit with their delusions of grandeur. IMHO, assertive, honest, respectful and professional folks who lead projects tend to attract better quality contributions and sustain development long-term than jerk dictators for life who may ragequit at any time if they don't get their way.

Re: A Sad Day for Rust

#945

Post by anon463637 » Sat, Jan 18, 2020, 7:40 AM UTC

kevinastone wrote: post #918

dbcfd wrote: post #460

Earlier quoted context omitted.

Right now, if you want async/await, you either have warp or tide. Hopefully gotham or rocket gets around to updating.

Gotham will be async-ready once this PR lands and the next release is published: https://github.com/gotham-rs/gotham/pull/370

Noice. To me, Gotham makes more sense because it depends on stable, whereas Rocket uses nightly. Anything depending on nightly seems inherently more fragile and un-future-proof (no pun intended).

Re: A Sad Day for Rust

#946

Post by anon463637 » Sat, Jan 18, 2020, 7:43 AM UTC

C14L wrote: post #611

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

Or fork the code. That's the great thing about FOSS.

Forking if it's mature and featured enough to justify it, but it maybe too unsafe broken to invest in rewriting large swaths of code. That's the perpetual trade-off of engineering decisions; whether to build, fork or buy.

Re: A Sad Day for Rust

#947

Post by pgeorgi » Sat, Jan 18, 2020, 7:49 AM UTC

mratsim wrote: post #884

sendilkumarn wrote: post #722

Earlier quoted context omitted.

This could have solved a lot of problems...

and introduce new flamewars about "Not-Invented-Here", why don't you contribute to a common codebase, ffmpeg vs libav/avconv debacle.

ffmpeg / libav had lots of bad blood long before the fork, which might have been the real driver for making it a "debacle".

GitHub in particular has a "fork" button to make it super-easy. So fork, do your edits. If you want, make a pull request with the original project. If they take it, great: the fork can cease to exist.

If they don't want to merge it don't take it personally but go your own merry ways. And this is what didn't happen with actix.

Re: A Sad Day for Rust

#948

Post by tus88 » Sat, Jan 18, 2020, 8:55 AM UTC

kragen wrote: post #940

tus88 wrote: post #931

Earlier quoted context omitted.

I wonder if authors consider "friendly" forks to be friendly ...

The XEmacs fork I mentioned had some bad feelings attached. As far as I know the other examples I mentioned (Stackless, swap-to-NFS, LuaJIT) don't. But it doesn't matter what authors think. What matters is what helps the users. Would you ask for Newton's approval before calculating a planetary trajectory, or Kalashnikov’s before designing an automatic rifle? Their achievements matter precisely because they empower ev…

Actually I agree, I wasn't trying to emphasize their feelings as much as question if there is really such a thing as a friendly fork. In reality it shouldn't matter and the concept be void, if someone forks your project and it is successful you should be glad you don't have to anymore and can do something else, as well as benefit from the improved software.

Re: A Sad Day for Rust

#949

Post by fluffything » Sat, Jan 18, 2020, 9:02 AM UTC

rowanG077 wrote: post #736

fluffything wrote: post #429

Earlier quoted context omitted.

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. `unsafe` is a PL term that refers to _soundness_. In Rust, an `unsafe { ... }` block is required to perform an `unsafe` operation, and it precisely means "The code in this block has been proven _sound_". If the code in the block turns out to be _unsound_, e.g., because the proof is incorrect, or non-existent, then the…

That's an interesting way too look at it. But that's not how it works in practice. Almost no one in industry is going to write proofs for their unsafe code. It didn't happen for C or C++ and it won't happen for Rust.

This is how it works in practice for the Rust compiler for the Rust standard library, and for a lot of foundational crates in crates.io. (Pretty much every well reviewed crate in cargo crate review either does this, or does not contain any unsafe code at all).

We also have tools that change for this for very large projects (e.g. cargo-geiger), and tools that help you test your proofs (e.g. cargo-miri). For some unsafe components, there are also proofs in Coq, and the proof systems for Rust unsafe code are making a lot of progress in both defining the rules that unsafe code must uphold in the unsafe-code-guidelines and the Rust spec, as well as in providing example proofs and a standard library of theorems that you can reuse for your own proofs.

Re: A Sad Day for Rust

#950

Post by kragen » Sat, Jan 18, 2020, 9:20 AM UTC

tus88 wrote: post #948

kragen wrote: post #940

Earlier quoted context omitted.

The XEmacs fork I mentioned had some bad feelings attached. As far as I know the other examples I mentioned (Stackless, swap-to-NFS, LuaJIT) don't. But it doesn't matter what authors think. What matters is what helps the users. Would you ask for Newton's approval before calculating a planetary trajectory, or Kalashnikov’s before designing an automatic rifle? Their achievements matter precisely because they empower ev…

Actually I agree, I wasn't trying to emphasize their feelings as much as question if there is really such a thing as a friendly fork. In reality it shouldn't matter and the concept be void, if someone forks your project and it is successful you should be glad you don't have to anymore and can do something else, as well as benefit from the improved software.

If you like what they added, you can merge it into your version unless they chose an incompatible license for their work. (That's one reason the GPL is so important: it prevents such incompatible licensing.) So if the forks continue unmerged, it likely signals some kind of difference of opinion: perhaps over technical quality, perhaps over tradeoffs, perhaps over licensing. The humans frequently turn such differences of opinion into chimpanzee factional dominance games similar to football, but in principle there is no need for that. I don't know of any LuaJIT users denigrating the hygiene and ancestry of PUC-Lua users, for example, nor vice versa, but surely it has happened on one occasion or another.