I mean I feel sympathy for a guy. A project you started on your terms and had fun working on it. Suddenly it starts feeling like a job and you don’t get paid (correct if I’m wrong.) Arguing with people who don’t get your point in an argument. I understand you should be able to explain it if people don’t get it. But I guess there is a limit how many times you want to explain something.
@@rich1051414 Isn't that the problem of most open source free stuff. Dedicated people share their code, get nothing in return, while those who use that code make the money while demanding that every software be open source so they can use it to make even more money without having to pay for the tools they use.
I like how in Clojure now people are beginning to donate to people working on good libraries. Not sure if others are doing the same now but it’s a great idea
Actix drama in a nutshell:: Rust community: You cannot just use unsafe code and not even marked it as unsafe. Actix dev: ha-ha, mutable references to immutable data go brrrrrr.
The whole point of unsafe is that you have additional knowledge and requirements that keep your code safe that the compiler doesn't understand. They never once provided him with a test that showed UB, but kept insisting on changing internal code to remove that additional knowledge requirement. That's fine and probably a good idea when there's a large team behind a project and you expect several people to be able to modify code and not worry about UB, but since he was solely responsible for the project, he had all those requirements internalised, and saw every such PR as a personal insult akin to "you don't know what you're doing, you'll forget how this works, you'll shoot yourself in the foot", etc. Just two incompatible points of view, exacerbated by a large amount of similar PRs.
I want to make this clear because people in this comment section keep getting this wrong. In Rust, code that says it is safe but isn't is incorrect code, you are violating the language's rules. That is not just a design decision the way it is in other languages. The problem was not that unsafe was used, nor that UB was possible. The problem was that the public API (even if internal) was marked safe when it wasn't safe at all. If that function had been marked unsafe, there would've never been a need for those PRs.
Agreed. People are replacing it with safe code because they can't think about writing bug-free unsafe code. It takes a lot of knowledge and then some courage to do it.
@@Treeniks just started learnng Rust and its definately great language which draws my attention, but there's just so much Zealots in the community, "you can't do that", "you're not supposed to do that", "thats wrong" - and this is what happens with actix-web. programming language is just a tool to build something, if the compiler or the machine process allows you to do what you are doing, then who are you to say "that is wrong". Rust is great, but a lot in the community is behaving like a CULT which you must SWALLOW what they want you to swallow. at the end of the day, the code is compiled into MACHINE CODE and any DAMN language does not even matter even so for the people who'll be using what we are building.
"Unsafe" code is supposed to be used for inner implementations to give performance or features. This is why "unsafe" blocks exist. And the features that were implemented here aren't even called outside the library, so there's no way for the user to cause it to malfunction. TLDR: He used unsafe blocks to gain performace, which according to Rust's docs is an acceptable use, in an app centric on performance.
That wasn't the problem. The problem was that he used an `unsafe` block in a function, but the function was marked as `safe`. However,the function wasn't safe at all, exposing unsafe code behind a 'safe' interface is _not_ valid / acceptable for Rust. Safe rust code could segfault if they pulled a reference out of the object and then reset the object, as shown in the example. If he wanted to leave-it as-is, he needs to mark the function as unsafe so that callers need to wrap the call in unsafe. The separation between inner-implementation details of the library, and the "user" of the library, makes sense if the library is written in C++, and the user is using it from Rust, because doing unsafe things in C++ is legal. But actix wasn't written in C++, it was written in Rust, so he too is a user of the Rust language and needs to use the language properly, which means wrapping unsafe code with unsafe blocks and exposing safe interfaces, which he didn't do. Otherwise it's just not Rust anymore. RedoxOS is written in Rust, that's the point, and it uses unsafe{} in rust properly, only marking functions as safe if the internal safe code cannot be abused.
@@npip99 I kind of agree: I think the function should have been marked as “unsafe”. Though I kind of understand why it wasn’t too. It was only unsafe if the “contract” of the function was broken. This contract wasn’t implemented in the language (unlike the contract of e.g. Rc), but I don’t think it needs to be when it comes implementation details.
@@npip99 Excuse me? This is what the official rust book says: "To isolate unsafe code as much as possible, it’s best to enclose unsafe code within a safe abstraction and provide a safe API" Maybe I didn't understand your point?
I think the issue here is the way the dev responded to this, just "no fuck off" and closed a potentially good solution. Just because you can use Unsafe{} doesn't mean it's completely okay to (or that you should) use it. The dev should have discussed this further with the contributor instead of being a jerk. EDIT: Okay i thought a little more about and I don't know, I don't agree with the "OSS is toxic" thing, I think if you are maintaining a oss project you should expect to have issues from anyone on the world, this is hindsight so idk
I think Rust as a great language but the community is mostly composed of fanboys, Rust is the superior language, the design decision of all other languages are always wrong, the only language that gets things right is Rust, everything must be rewritten in Rust, even thing where it doesn't make any sense at all. Quite frankly, the author should have said: fuck off, I will rewrite this in C++ and deal with it. Undefined behavior is not always bad...
i feel bad for the maintainer. he probably loved working on his project at one point and then it became too stressful. i dont think its fair that everyone was pressuring him. the point of open source is if you see a different vision for the project then fork it and continue. the community was feeling too entitled imo.
@Ryo Sanada I honestly amazed by the fact you could separate between "mean people amongst a host of reasonable people". either you're stupid wise, or you're guilty of it yourself. or maybe just naive.
It's not entitled to expect defined behavior in something implemented in Rust. There's no point in using Rust if you're going to defeat its safety features. It's inappropriate to lash out at people who volunteer their time to eliminate unsafe behavior in a Rust project for an absolutely minimal performance impact. His ego got in the way of other people's security. Moving the project to his personal account was beyond unreasonable; it was deliberately breaking other people's code just to be a dick. The community was justified in responding with hatred.
@@JB52520 He could have never released the project in the first place or never made it open source. Bitching at someone because the work they did - for free - that you are exploiting, because you don't like how it is implemented - to the point they evidently have a nervous breakdown because of it is OK... Why? If you depend on someone else's work when that person had no obligation to let you use it in the first place, complaining when they get stressed out by endless demands from strangers who tell them you're doing it wrong is, frankly, petty and entitled. If you don't like how a project works, don't use it. Nobody forced you to. Oh, but you chose this particular library because you liked what it did, but now you're bitching at it's creator about the very thing that makes it function the way it does being 'wrong?' Ultimately this is the kind of stuff that risks killing the open source community. Why open source something if you know doing so will get you endless grief?
@@JB52520 Protection from UB that is not shown to be able to occur (via, as the maintainer asked for, a unit test using the public API) is going to be a low-priority fix *at best* for any maintainer - as it should be. The first, overriding principle in software is that it does the job. Was actix broken? No. Might it have been? Sure, but the submitter didn't show a practical example, only a strawman. Rust's safety guarantees are not intended to be the overriding concern. They are only a tool *not the goal*. And given actix's position vis-a-vis speed, the submitter should also have submitted a comparative benchmark showing the effect of the change - since the change wasn't otherwise fixing an extant *bug*, they should have at least shown that it didn't make things worse. Minimal changes are not null-changes, and an accumulation of seemingly insignificant inefficiencies can add up. Could the maintainer have been more civil? Perhaps. But the submitter had no special rights here - the maintainer put orders of magnitude more work into the project, and deserves orders of magnitude more deference with regards to it. I would expect no less on any project.
Ben, you are possibly ignoring a major fact: he is NOT a native speaker of English. Moreover, written communication is hard; even for natives. Couple these facts with the lack of empathy and straight-out entitledness, and you'll see this drama in a better light. Because in the end, despite our earnest efforts, we're humans and not coding machines.
@@enzo.albornoz I think for someone who speaks the language non-natively who has not been immersed in the surrounding cultures, their tone can quite often get misinterpreted as rude in my experience. I suspect that's what's happened here as well
as a non native speaker, i kinda feel the pain. i have trouble choosing the right word to express what i meant. internet being internet, everyone automatically assumes the worst.
That's what forks are for. You think your design priorities are better than the original project's author? Fork and demonstrate to the community the benefits of your vision.
Please god, don't fork a project used by lots of people unless there's a fucking amazing reason to do so, or it's just for your own use. This particular issue was clearly no reason to fork the entire project.
@@mateowang6570 if it's for your own use, there isn't really. The issue is if it starts to fragment the community, more choices isn't necessarily a good thing for users, particularly if there is no clear reason to choose one option over another. Also is work maintaining your new fork the best use of those resources or would that effort be better spent elsewhere (such as contributing to the original). That's not to say you should never do it but you really should have a good reason.
For the rust newbs.. unsafe is a helpful tool. It's a signpost to say that basically, you know what you are doing. You can wrap that unsafe code in safe interfaces. This is the point. Unsafe blocks don't make unsafe code. Particularly if it is wrapped up in safe interfaces that guide consumers on how to use it. Unsafe isn't "BAD" either; it's simply a tool. Use it, but make sure you know what you are doing!
While I agree making the repo private was a bit heavy-handed, any company depending on the code that didn't keep a copy locally was just asking for trouble. I know at my company, we use quite a bit of open source software, but it's all imported into a private company repo first, from which we pull the code into various projects. That way, if the public project disappears overnight, we have all the source and artifacts in use up to that point.
There are 2 fundamental reason why actix-web ended up like this. Firstly, it was too good performance-wise. Secondly, it broke the 1st Commandment of Rust - "Thou shall avoid 'unsafe' at all costs". It was not going to last. Imagine, a solo-dev with no prior stripes to his name made a web framework that trashed everything that came before it on TechEmpower's ranking charts. What's worst, he did it by using Rust and breaking its 1st Commandment of writing Rust-ic code -- 'unsafe' everywhere. Immediately after actix-web was crowned #1 by TechEmpower, everybody started to go through his code character by character. That is why everybody in Rust-land knew his code better than him, that is why they were pointing at non-pub functions. I even remember a discussion on HN on something related to web servers and someone causually mentioned "actix-web". Then immediately, on each refresh of the page, you saw new replies popping up saying the dev of "actix-web" was cheating his way to the top by using 'unsafe'. This was a death by a thousand cuts. Also, notice there was never any talk in the Rust community of forking "actix-web"?
@@Wzymedia well I cannot judge. But having preachy people all over the place sounds kind of horrible to me. But I dont know the real situation. You know, using unsafe code to have a fast service doesnt seem necessarily wrong to me and I wouldnt call it cheating either. "Use this server with a lot of unsafe code and you get fast performance" sounds absolutely fine to me.
@@Jossnaz if you look at the PRs for the fixes of 'unsafe' you'll see it would be rather easy for any of these "fixers" to fork the project and fix it, but no, it was far too easier for them to stay one side and critize the maintainer.
That's a stupid commandment, really. I think Rust being split into "safe" Rust and "unsafe" Rust is one of its biggest strengths. However, to be honest, I saw this one coming from a mile away. The second you make a decision where you sacrifice performance for safety or vice versa, you'll have people tear you apart because half of them ain't gonna agree with what you did. And the "unsafe" keyword only makes this decision stand out like a sore thumb in your source code.
The "this patch is boring" message was in a response to someone who 1. Showed that you can cause undefined behaviour from the public api 2. Provided a patch to fix it That response was IMO totally unreasonable (as many other maintainer's responses anyway). I am kinda sad that this got widely interpreted as "Rust community roasting maintainer for using unsafe", while the problem wasn't really the usage of unsafe but maintainer's attitude and people getting upset because of it.
Also for comparison - that issue was one of the many unsafe related issues that author opened on various repos as a part of work on his article. All those projects responded in some reasonable way, whether they did something about it or not, except for actix, where the maintener went straight away into defensive mode without any meaningful response.
So what? There is UB but UB is not always bad. It could be that you will never encounter that UB with a sane use of the library, and in contrast resolving the UB will probably mean a performance penalty. Rust unsafe is also a way to optimize code, if you know what you are doing. I use unsafe a lot because I know what I'm doing, damn I wrote code in C and C++ for 30 years and nobody questioned about the fact that is super dangerous I should not do that, and now in Rust is a problem? I know how to write code and thus I use unsafe when using it does make sense, even at the expense of some UB derived by an incorrect usage of my code.
@@panstromek I dont think maintainers attitude was a big problem but the communication. I understood what he was trying to say and I see that majority of the programming community wont understand it because the way he wrote it. If he would had spent more effort in explaining his thinking it would not have exploded the way it did
There was definitely dog piling on the maintainer. People seem to hate actix with a passion. The amount of people declaring 'i will not use actix!' seems bizarre considering how much software I personally do not use, on the daily. The first bit was helpful the dogpile not so much.
This is major conflict between web only programmers and traditional native programmers. TL;DR I find too many programmers are used to writing in managed environments without ever having to learn to manage memory themselves and it leads to inexperienced devs expecting a tool sort out all of their issues and expect modern hardware to be the answer to poor optimisation. -- Bit of rant below I'm actually a rather young developer, originally self taught up to the point I went to university, thankfully at that time we still had a lot of old school professors who wrote in older languages and a solid understanding of how things work at the very lowest levels. One of there ways of teaching us to write good code from the get go was to make us learn assembly and write programs in assembly, it was never about learning assembly but it was to instill in us how to write code that was functional, well written, how things work at the lowest levels and to make sure we properly understood memory management and concepts around it. I see far too many self taught programmers taught from online courses that are more often than not made by people who've never learnt to program out of a managed environment with a huge toolchain that will make sure you code is almost always going to have behaviour that's expected or will even fix bad code for you. I personally don't think this is a good way to learn to program, yes the tools are useful and once you've got the experience and skill to write decent code without assistance you can use these tools but you should never rely on them. Programming is something you only get better at with experience and with trial and error, when you're being handholded through the process and relying heavily on manage environments to make sure you don't do anything wrong you're not learning anything other than to write that one specific thing in the safest way possible that the setup guides you towards, it does not provide you with ways to experiment with more error prone code (unsafe code is not unsafe, it just means it has a higher chance for things go wrong if you're not careful) to make something that runs faster or has more flexibility.
Exactly. Bro, these new languages have ruined people's brain. People think they can write anything and compiler should do the rest. People don't have brains anymore.
Maintainers can learn a lot from this. It’s ok to say ”I’m not motivated to review this”. You should be clear but polite. The hard question is how long you should keep a PR open if you know you’ll never accept it. People get bummed out when you close it too fast - but as a maintainer it’s nice to get rid of unnecessary open PR:s - and by leaving it open you could give them false hope. A solution would be to be honest you are considering closing it - but let the creator respond. I think what ticks people off is when you close PR:s instantly after a brief comment as that seems rude and rushed.
When I read that "I must be braindead", I'm getting the vibe of him feeling insulted. I don't think he thought about others. Internal to him means, he has oversight of any changes, thus UB in internal code must mean that HE missed it.
You are wrong. Internal code means, no body can mess with the code, so there is no way that UB can be produced with the code. Actually the PR UB demo code was created by a brain-dead and supported by other brain deads. Unfortunately they didn't even understand the meaning of the comment, 'I must be braindead'. Such a shame.
I imagine the most frustrating thing for the maintainer are all the PR's that don't actually SOLVE PROBLEMS but just rewrite the existing code. I also hate that people encourage this, I have seen youtube videos about "How To Contribute To Open SOurce" and it tells you to start with something easy, like doc typos or in this case, randomly refactoring unsafe stuff. If you wanna contribute to open source, find a project with an active bug tracker or TODO list and start there, not random improvement suggestions!!
I can't stand those kinds of videos: they encourage new programmers to contribute to a project just for the sake of contributing to a project. If you want to contribute to OSS, that's great - contribute to a program that you actively use and understand. Strolling around someone else's codebase looking for things to fix or add is just going to cause friction like the pull requests in this video.
ice cold take: there's nothing wrong with correcting doc typos. it makes things more searchable, helps with people who use screen readers, helps nonnative readers of the language, helps anyone with visual processing disorders, and gets people at least used to the process of how PRs work I'm not gonna comment much on refactoring because that's case-by-case - i think it's something that inexperienced devs do more often BUT there are definitely times when refactoring improves readability and maintainability.
@@polimetakrylanmetylu2483 agreed, the change is on "private" part of the module and nobody will use it like example without deliberately placing such case on the actix codebase itself. it's like complaining about an unsafe door on top of locomotive that people can climb out with a ladder (that shouldn't be inside when the train is running) going up and smash their head to one of the narrowest tunnel that the train will go through only when the main railway and the secondary railway is on maintenance which is super rare. and the proposed fix is removing the warning sign on the door and weld the door. and the old maintainer does not agree because the door have a legit use on maintenance or smth.
I'm frustrated that this video again perpetuates the idea that this was about unsafety existing at all. It wasn't, and people keep using this to perpetuate the insanity that Rust's mantra is "Avoid unsafe at all cost!". That mantra doesn't exist. The issue wasn't that unsafety existed, it was that it was hidden. When a function in Rust is unsafe it needs to be marked with the "unsafe" keyword. It doesn't matter that it was internal code because the unsafety mechanism exists to remind the developer that an operation may be unsafe, that includes maintainers of internal code. The solution to this would have been either to fix the unsafety issues, or mark the code unsafe if the developer doesn't want to introduce a performance hit. The developer here refused to do either.
But if Rust is all about safety how it allowed to compile an unsafe code without marking it with 'unsafe' keyword in the first place? Isn't this defeating the purpose of unsafe making it optional keyword?
@@ke5uq1we8h The compiler does require unsafe code to be marked unsafe, and it was. It was using unsafe *blocks* inside of functions, and not marking the *functions* themselves with the unsafe keyword. So callers of the function wouldn't know it was unsafe under the covers. Rust doesn't require every caller to be marked unsafe because a code block somewhere in the program is unsafe, that would be silly. It only requires callers to be marked unsafe if they call a function marked unsafe, that's why people were asking for the functions to be marked unsafe and not just code blocks inside.
@@MonkeeSage So, unsafe block of code inside a function doesn't render that function unsafe, but calling an unsafe function - does. That is, an unsafe function will drags its unsafety all the way up the chain of calls until an unsafe block of code, which effectively stops the notion of unsafe code from spreading. In my opinion, Actix developer fully meets the language rules by concealing unsafe code inside a block according to said language rules.
@Layl Bongers Your comment shows a clear lack of understanding of how unsafe code works in Rust. Take a look at ua-cam.com/users/JonGjengset - specifically "Porting Java's ConcurrentHashMap to Rust" - a 3 part series @MonkeeSage is bang on the money.
I can say that open-source can be extremely frustrating from the contributor end as well. Having maintainers just turn their noses up at contributions that you made in good faith and poured hours of your time and effort into is disheartening, to say the least. I've stopped contributing for the most part, I just modify things for my own needs.
Agreed, that kind of behaviour just results in code being forked and maintained by someone else. That works - but nobody wants to have to pick between 5 different versions of a single codebase. Taking personal offense to contributions is unhealthy for the community.
“Something we’re gonna see in open source projects that’s gonna happen from now on”… Open source software has been around for almost 70 years. This type of drama has been happening for at least that long. It is certainly nothing new.
This is where I think we can also learn from the Rust project itself. A clearly defined set of philosophy and processes can help with these decisions quite a lot
This reminds me of the left-pad issue. I honestly hope this happens more often to get people to realize that depending on github repos and npm packages is not always the best decision for every dependency. Personally, I like to put the frozen code dependencies directly into my projects in certain circumstances. It's not always feasible, but in hindsight, adding code of left-pad would have been way easier to deal with than the broken dependency when the maintainer removed it.
@SLKA a bit late, but bad versions of cargo crates are yanked. You can't get yanked versions into new projects, but if you have project with yanked version it remains there in working condition.
What I learned from this is : everything can or can not be unsafe depends on how you use it. Like that you are supposed to use soap to wash your hand instead of eating it.
2 роки тому+1
If you don't use unsafe it won't. Your statement is only valid when you use it. The main advantage of using Rust is to be fast and safe.
I won't comment on the human aspect of things, but let me clear up something about the technical side: Rust's guarantee is that, any code that isn't in an unsafe block, is safe and always well defined. When writing unsafe code in Rust, it is your responsibility to either make the public API unsafe as well, meaning the caller will know your code can cause UB, or make sure the API is 100% safe to the outside and UB is impossible. In Rust, this is not a matter of internal vs. external code, it is a language guarantee that must always hold. Rust is not C++. In Rust, UB in safe code is not a design decision, it is incorrect, you are violating Rust's safety guarantees and thus violating Rust's rules. Unsoundness in safe code is incorrect Rust code. Again, this is not a design decision of a project, it's part of the language. I get how this may seem strange or limiting to the outside, especially coming from other languages, but Rust works different. Even if it is internal code, if one can achieve UB in safe code, that is a bug by Rust's definition and should be fixed 100% of the time, no exceptions.
C++ and rust agree that a program is not well formed if UB can occur at runtime (safe, unsafe regardless). But you are making a stronger claim: that it is not just convention but a language guarantee that safe code could never possibly cause UB no matter how it is written (and you need this to be not only convention but a language guarantee in order to say that this is a "bug by Rust's definition and should be fixed 100% of the time, no exceptions"). Is there actually a rust language spec saying a program is not well formed if, after possibly replacing the program with a different one differing only in the safe sections, this new program can cause UB at runtime? To my knowledge, the only existing spec for rust is rustc, which does not prohibit such programs. That leaves this norm as merely a (strong!) convention for writing rust. There are conventions for writing many languages, but failing to follow those conventions is usually not considered a bug. The program possibly misbehaving is a bug. In any case I agree that open source libraries should follow the strong conventions of the language, but I think you are overstating their transgression.
@@austinconner2479 It's been a while since I wrote that comment, but if you write safe code only (i.e. don't use any unsafe blocks) then Rust guarantees you that no UB can happen. If rustc still causes UB, that is considered a bug and an issue needs to be opened. It's the same for the STL. Rust's whole design revolves around that idea, so it is much more than just a convention. You are right though, technically rustc is currently Rust's spec. But again, safe code causing UB is considered a bug in rustc's terms. Other than that, there is a Rust Reference book and although it is explicitly not a language spec, it's the closest that we have currently. The Rust Reference book states about unsafe blocks: "When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context" which I interpret something like this: When you write an unsafe block, you are signing a sort of contract with the compiler that your unsafe block will not cause any UB in it or the surrounding safe code. If you violate that contract, rustc is allowed to do whatever it wants. Of course rustc won't prevent you from causing UB in safe code through unsafe blocks, the point of the unsafe keyword is that the compiler cannot check if what happens in it is actually safe. But rustc still expects you to uphold that contract. My wording might've been a bit extreme in my original post, however an unsafe block that causes UB in other safe code should absolutely every single time be considered a bug. It is certainly much more than just a convention and the Rust community will tell you so, as what happened with Actix Web.
I found myself on the side of the maintainer multiples times, except when he removed the repo (greasy BS, just stop approving PRs). I could be totally wrong because I've never used Rust and don't understand the interpreted languages switch comment, but: 1. The issues only arose when people were using non-public, internal functions. Anyone who had been using these unsafe functions and getting away with it to this point (would || could) now be screwed with these PRs. If that's the case, they should have forked and made a 'safer' version of actix. 2. These issues are very unlikely in production and thus 'boring pr' rings true.
In response to your first point: in rust, it is impossible for library consumers to call internal functions. They cannot bring then into scope. Same goes for types, macros etc. All you get is what's been explicitly marked as public.
Eh... Rust is mostly meant to not have all the shenanigans that are common in C code. Which in C, the libc and stdlib libraries are actually a vector to break into a computer. Particularly through the printf syntax that can be used to break stacks and run arbitrary code. It requires a lot of ground work and study--and breaking in this way _will_ show up in log files... and most computers will have daemons running that can be all, "yeah... something is doing some FUN with libc/stdlib"... ... but Rust is meant to be a bit of software that can run without a daemon making certain other software is playing safe with it. So even if a routine is internal and not public--that doesn't mean it cannot be used as an attack vector. Hell, tar(1) has had (very specific patch level) versions that you could get root access to a system via timing a racing condition properly when the extracted files are being given permissions on the file system they are being written on. An exploit that--nobody really knows how to do--except making two people in the world... but Tar still got patched regarding that. Mostly to keep it that way. So... I understand why Rust would want to have these lofty goals... and I do think these goals are really lofty and Rust hasn't gotten them... but it is nice to see what happens when they are attempted. I just wish Rust's community would stop acting like they've gotten there already.
@@NimhLabs you're absolutely right that an unsafe internal function could be used as an attack vector, but in order for an attacker to reach it, the consumer code also needs to be broken to the point of allowing a user to call an arbitrary function pointer. As long as the consumer only writes safe rust, and we assume no exploits are present in Actix like the author wants us to, it won't be any more an attack vector than any other piece of code on your device. That said, I hope I'll never need so much web server performance that I need to blindly trust code written with the Actix philosophy.
@@iwikal Are you suggesting that Security Through Obscurity is completely fine? Also... with exploits similar Shellshock happening maybe about twice a decade, the issue isn't so much the consumer writing code. That being said, I don't think Rust has completely gotten to where it wants to think it is with its Safe code philosophies... but I admire that they are making an attempt. The Rustlang community seems to be full of people who smell their own farts.
Seems like the root cause of the problem is that open source needs maintainers in the first place. First of all, no one is entitled to a repo owner’s time, and the “implied contract” of open source that one of the GH commenters mentioned is not actually a thing. Open source means you can click the Fork button and do what you want. It doesn’t mean community development, and it doesn’t mean a project owner has to maintain a project in service of a community. I think what open source needs to permanently solve the maintainer problem is a trustless and participatory mechanism for determining consensus. Basically a low-friction and very efficient or automatic way of “voting” your use of the project in favor of, say, removing unsafes or aligning with the original author.
also, fragmentation/ variants is a welcome thing most of the time, not all solution will work out the long term, having multiple variants means the better solution will prevail over time or an external change (new compiler features, etc) will make the the split unnecessary. we had such split that later date were merged like how it happened on node.js and io.js split and merged later on.
Undefined Behavior exist in several other languages as well, not surprisingly C and C++ included. But it's not necessarily when you corrupt memory, it can invoked from a lot of different behaviors.
If the author decided to flow the path of unsafe code, and he knew what he is doing, and the project hits the top of performance in benchmarks, come on, stop crying. Accept the fact that the author did the hard work, that he has a life, family, and don't want to do people's will for (in his vision) nothing. Be ashamed of this child attitude, fork the project, remove all unsafe code, get community around and move on. neovim do that and it's all right.
No conscientious developer intentionally releases unsafe code for the sake of winning some perceived benchmark competition. That said, if your use of the code is mission-critical and the maintainer couldn't care less about your mission, you should by all means fork it. You are ultimately responsible for what goes live in your production environment.
@@diggydude5229 In rust "unsafe" only means "unverifiable at compile time". It can and usually is completely safe well defined code, if it is written by someone who knows how Rust works. Unsafe rust is a hell of a lot safer than anything written in C / C++. Also some people are using "unsound" ambiguously. It isn't undefined behavior like they are trying to imply. It is like accessing the kth element of an n-length array. It is totally defined whether this is correct or not, but if you do it wrong then it will be incorrect.
I have grown to be a big fan of Warp. The filter model can be overwhelming, but once we wrapped our head around it, it is actually very powerful and well thought out.
it looks really good. Rocket is upsetting to me so I'm trying to find a better framework (I came from node/js and I liked koajs/svelte not react/angular stuff). I also wish they'd put tokio into base rust already
@@GrandpaRanOverRudolf Interesting, in node/js we use joajs as well, and it's very clean. Btw, on the Rust side, I am moving to Axum. It is very well designed, not too high, not too low, and well componentized. Working on a video tutorial as we speak.
I should add that saying "it doesn't even have pub(crate)" is not "it's not pub". It means it's contained within the specific module he wrote it in. Any unsafe code sort of makes the whole module it's in unsafe, because people calling the unsafe code have to do things properly too. That's why you abstract it into a module. What the dev is saying is that he contained it within a module, hence it's fine because people modifying that module should know about the unsafe code within it. He's not even arguing for general additions to the crate to have to deal with the unsafe, because it's not public within the whole crate.
I use rust heavily but I must admit some rust fanbois are one of the worst groups of people in programing world. They have difficulty to understand how real world work and how people work.
I have given up on the Rust community as well. To do anything real, you have to do a lot of ugly unwrapping, Boxing, and other annoyances that makes writing Rust a pain in the ass. Doing Haskell instead!!!! :D
@@friedrichdergroe9664 I wanted to transition to Rust from C++ about a year or so ago. The community made me resent it. I felt like it always was a cult, praising Rust whenever possible. I mean the language is ok but didn't really have a good reason for me to make the switch.
@@Frozander Yeah, they can have attitude. I wonder if has anything to do with the nasty attitudes going around at Mozilla at all? Or as I like to call them, Marxilla. :D
@@neociber24 Just because this behaviour exists everywhere doesn't mean it isn't RIDICULOUSLY bad for Rust. There are shades in everything, but Rust most definitely HAS a problem. I'd hands down put them as the worst community of all programming languages. Even the most fervent functional programming fanatic is child's play in comparison to the average Rust user. But then again, this behaviour stems from the very top of the Rust echelon. When your own leaders endorse shitty behaviour "FOR THE RIGHT CAUSE" (big quotes), how can you even expect your users to behave differently?
I can relate to the maintainer here quite strongly. Although i am not a rust dev and don't understand the severity of unsafe i can compare this to 'any' keyword in typescript. Something completely different but the idea is same. Avoid using 'any' at all cost. But it exists when you have no way to properly define the type for an argument. Seems like maintainer made sure that there wasn't any ub in his logic still people kept pressurize him (for years) to remove it because of some unwritten rule in rust community or an easy way to get listed as a contributor.
Yes, he should have done that. He is perfectly right to use unsafe everywhere he wants. It's his project. In the other hand, if you decide to do it so, you also must accept the criticisms, and accept other people saying "don't use unsafe" when you can avoid it. In the end, you control your project.
Yeah he was, but it would be better to detail his reasons in a contributor guideline so that people don't end up writing PRs that keeps being rejected for some unknown reason.
@@WorstDeveloper - I agree, I'm going over Actix, Rocket, and Diesel now. It's really fast. The type checking and compiling reminds me of TypeScript. Hopefully Ben will make videos on Rust. ;-)
The public APIs were not dangerous. The bugs would have only happened if someone deliberatly used the code incorectly. I wonder if the speed decreased or stayed the same with those refractors.
Thank you very much - we are in the process of going open source with a project. Our community guide lines will include the possibility that a commenter can be banned for not being constructive. Secondly the developers will not be the ones to decide of which comments should be answered or not. Those rules are there to protect the developers from smart asses like all the professional "dislikers" on youtube. Secondly some developers are not born as diplomats.
I personally think that the community's response is pretty natural. One of Rust's core values is guaranteed memory safety and thread safety, and one of the fundamental rules when writing Rust code is that all safe functions (those not marked unsafe) should guarantee them. This rule extends even to internal code, because if people were to inspect or work on these code, they will assume that safe functions are actually safe. As is shown, this project had several places where the safety guarantee was broken by safe functions. Specifically, the issue at 12:15 cited a piece of code that handed out multiple mutable references simultaneously. This was stepping on the core value of Rust, and of course the community wasn't happy. Perhaps one reason for all this is that the original maintainer took their philosophy on software development too far. They thought that software development is a creative process, and on this basis, they rejected things that are not creative. This led them to disregard these issues and PRs mentioned in this video, uncreative yet solve a big and very real problem - people who work on the internals of this library may use these internal safe functions as if they were actually safe, but since they're actually not save, potential problems emerge. There's still one thing that I'm not sure about. Why did the original maintainer outright disregard the fundamental rule of writing Rust? Does it also has to do with his philosophy? With all these said, I'm not saying that it's all the maintainer's fault. The exchange between them and the community certainly has to do with the outcome.
I want to give my 2 cents for this. Rust is a language that is made to be save and that states as a convention it states that unsafe should be avoided if possible. I also think that most of the potential problems with the code could be prevented at compile time, if you could tell the compiler to fail on certain patterns that dont really make sense. I think that the maintainer could have handled this by explaining and not rude comments.
At 7:13, I think the maintainer means "Give me an example of what you mean. Assume I am brain dead." Or "Give me an example and explain it like I'm five"
It's more like "Your example assumes I don't know what I'm doing" because it was internal code that only he would have written, but he wouldn't write unsafe code like that, because he isn't brain dead (I'm just assuming).
This reminds nothing of that though. Because NPM/node's package management does not work like Rust's Cargo does. You literally could not achieve the same situation under Cargo. which is why people love Cargo. Because not only is the system versioned incredibly well, the compiler toolchain is also versioned - so let's say a project dies, and stops working under newer versions of rust, breaking compatibilities or whatever, the toolchain itself can easily be used where those things are compatible. This is not the case with Node and NPM either.
It's weird to see people's takes on this especially people who don't know Rust. All of this seems like it could have been solved by sitting down with the original maintainer and telling him how unsafe works, how to label it and why UB is bad. He did not need to remove all unsafe, just label it correctly. If he wanted to make sure it was fast then he needed benchmarks between safe and unsafe. Rust safe can be faster then Rust unsafe. He seemed to be very much in the wrong as having any Compiler UB is not ok even in internal code. Even worse for Rust since it optimizes based on language garentees. UB can manifest in many different ways from different compilers to architectures. You do not need to call the function with UB to even see the results. UB can cause incorrect compilation making bugs almost impossible to fix or track down.
New to rust as of today. Kept pausing your video to read reddit and github about this problem. Still debating actix, rocket or gotham for web api. Comming from node, all of them are faster anyway so I don't care about benchmarks "cheating".
On the topic of "unsafe". The maintainer outs himself there: "Maintainers must know how everything works." That isn't a scalable situation, when projects develop, eventually nobody will know how every part works. This is why we use abstractions, and why things like unsafe are a problem even in internal code. Seems like there was contention between this project being a fun project the maintainer built for one thing and it being a production scale project that it grew into.
it's his code, he's not being paid by some big corp for it. He does it on his spare time. Also "unsafe" is complete nonsense. C/C++ has been doing this since forever and they don't have a problem.
i dont understand, why didn't he just close the issue and ignore them? Like if they want to program with a different ideology why cant they just fork the project and continue there?
I can kind of understand where this guy is coming from. I think the conflict arises from a misalignment of interests between him and his users. I think I would characterize him as a sort of speedrunner type of programmer. First and foremost, his interest is in pushing the bounds of what can be done with optimization to make a web server run faster, and everything else, be it safety or usability or any other beneficial characteristic of software comes second. If it doesn't help speed, it's not interesting. If a suggestion is detrimental to speed, he might find the mere suggestion to be personally offensive. On the other hand, the community are business programmers, the sort of people that would actually use a fast web server in production. Their primary concern is the bottom line. They want speed insofar as it reduces costs, but any sort of risk of undefined behavior whatsoever also introduces liability, and reducing that could even be a higher priority to them. So they want provable correctness, even if it costs some speed. Now what I would say is that maybe, if you're one of the community members, perhaps this project is not what you're looking for, though perhaps a fork of it maintained by somebody else might be.
The unintended behaviour did not happen when using the public APIs. It happened if someone forked the code and did something bizzare in private code (and also tied it up to public API)
Feel bad for the maintainer, probably had well thought out reasons(tests, benchmark maybe?)for using unsafe then being asked without tests, benchmarks to change code by "Jonny Whoknows" Have done the same document request , merge & prepare to throw Jonny under the bus!!
Your video title is more destructive for Actix Web rather than the maintainer giving up. More people will come forward to maintain. but if anyone watches this video before starting a project, he might not use this framework.
This somewhat reminds me Golang community where every newcommer is asking for this or that feature and what not. If they would implement or merge every PR ... the language would become total garbage. So there should be heavy censorship. Same there. He is the author with his vision. He is kind enough to review the PR. Somebodies ego is hurt by his attitude. Somebody wants him to be soft and nice. I totally understand that guy. If somebody wants to eliminate Unsafe he is free to fork and work on his own. No reason to make drama.
That's true to a degree. Actix-web is an amazing project and the author is a brilliant programmer..BUT the use of unsafe can very controversial in the Rust community. It's a kind of necessary evil. Too much unsafe begins to unravel the entire idea of Rust's safety guarantees. It was a legitimate concern and the author's position of "I know what I'm doing" isn't exactly reassuring. Having said that, there was a lot of unreasonable hate directed toward the author of a fine project.
I'm still using it. Even if it stays unmaintained, it still does what I need it to and until something better comes out I am not willing to change just because at the moment it's not being maintained. Even if no other changes happened unless some framework was considerably better I will stay with actix because its freaking fast and very elegant. I think the maintainer of the project felt very insulted. He makes this amazing server and because someone else doesn't understand how things are working in this framework on a very low level he decides to just make a bunch of changes, not based on fact but on theory, doesn't benchmark his changes and then demands a pr. Yeah I'd feel frustrated to say the least...
The problem with the people complaining is that they are using/thinking about the "safe/unsafe" idea completely wrong. You have safe and unsafe code, because you wrap your inner workings of your library (which is why he keeps talking about it over and over that it's not in "pub(crate)") meaning, those functions or types, are not exposed on the API boundary. You *can't* call / shouldn't call those things from the user perspective of the library. You can only call that, if you are doing *internal* work (meaning; you are working *on the actual* library itself).
The title is very misleading. I wouldn’t name it that way for the content you provided. The content is interesting though but nothing to do with the downfall of the framework, at least to me 😊
As the new lead maintainer of Actix Web (since September), it's sad to me that this video is still the first result when searching "actix" on UA-cam. Version 3.0 of the framework was carefully planned by many contributors over many months and ensured that known UB was fixed and *all* remaining unsafe blocks were vetted. This video is important for historical reasons but it is by no means the current state of the Actix project technically or organisationally.
Thank you for replying here. I am just doing some hobby project in Rust, and Actix Web seems like a great match, but these stories are off-putting. Seeing the currently active devs still supporting the project this way is great motivation!
Well tbh i think that the only "healthy" way to maintain an open source project is to be like Torvalds aka to be a reasonable dick. Maintainer shouldn't give two flying fucks about emotions of the community, they can hate him, love him - doesn't matter. What matters are code, facts and provable evidence, if you can't even formulate a reason for as to why your code should be merged, and prove it to the maintainer then well tough luck go make a fork and maintain it yourself. Drama shoudn't be adressed at all, wanna cry a river? Yeah, sure, go do that with snowflakes over there, you can pat each other on the backs while at it. Maybe that will cause some of them to toughen up and make their own fork of it. The only real reason why any controversy of any sort should ever affect the code is when maintainer went nuts and started adding malware to their code and even so, what i think community should do is not trying to pressure original maintainer to do something about, but create a fork of it. Oh and that issue of "other projects rely on THIS REPO" is just gold. It perfectly summarizes what i think is wrong with current developers. No one is obliged with keeping THEIR repo up, so the risk of it going down is always there, therefore dependencies shoudn't be downloaded live from their respective repos in the first place. Yeah it's much more convinient than traditional way of downloading them yourself or through centralised means, but that's exactly the problem: it encourages dependencie hell. Another problem with this "issue" is that instead of forking the library/rewriting code for it to rely on a mirror repo/etc. he is crying to the maintainer to guilt him into fixing other peoples issue. This is wrong on too many levels to even attempt to break down here. Oh and that "respecting your code" is just a peanut on top of that dung pile, why should i care about other people thoughts on my code? They don't pay me, they don't know me, and i don't know them so why should i care? For all i know they are just a bunch of code monkeys that collectively decided that shit pile worth its weight in gold. Drama is detrimental to any work being done, the best example of that is freeems project. It's the project that never really took off exactly because maintainer loved drama, for crying out loud he even tried to take the fully independant alternative project into that cesspool of meaningless drama by accusing him of stealong something from his project(even though the rusefi is structurely different from the freeems, like in every way imaginable, oh and ofcourse freems guy never bothered to provide evidence as it is common with drama queens)
IMHO I think a maintainer of project has his rights over the code he wrote irrespective of what open source community thinks / expects from him. Imagine the amount of work it goes to write something of this scale. I don’t agree with what the maintainer said in those comments but without the actual numbers / methodical proof of what the pr is about, I can understand how hard it can get to think in terms of people contributing or making those prs
Since they're already using unsafe, wouldn't it be faster or at least the same performance if they implement the same thing in C? Using UnsafeCell is basically just a bloated version of using raw pointers in C
community should've just forked. What do they think FOSS is about? They think they can do better, then go do that? Why bully the guy? I don't know why he went along with it either. Sucks.
I dont like the mainteiner approach. Sure, you have to be braindead to do that but there is no point on using unsafe. Even if you call clone, it doesn’t mean that the memory gets duplicated, thats the magic of llvm and rustc
This doesn't apply to most open source projects, the reason why it's so hard being a maintainer of this particular project is that virtually no one is using it, hence no extra passive income. If it were something like React or Redux, the maintainers can run it like a business, selling books and tutorials and stuff. The lesson should be, don't spend so much time to maintain a project that only a few people are using.
The maintainer was at fault, he used unsafe everywhere where it wasnt even needed leading to potential security holes and he was a engineer at Microsoft he should have known better and when people tried to fix it he told them to F off.
I get being overworked and not having enough capacity to dive into the details of pull requests. Despite that I think the maintainer handled the situation terribly. Memory safety is the defining feature of rust. It is a widely accepted best practice to make sure that no undefined behavior can occur. A project that deviates from this widely adopted practice should make sure to communicate that, something for a CONTRIBUTING.md which rust doesn't have. Moreover, if you don't have the capacity to thoroughly review a pull request, say so right away.
Just having 2 outstanding mutable refs to the same object is UB? _That's_ the reason why unsafe is not for everyone: not everyone even understands what actually triggers UB!
For the Rust compiler, this is UB, and once you have two mut references, the compiler can do whatever it wants with your code. In other compilers, it might not be, but Rust assumes that this doesn’t happen, and optimizes based on it.
That is the whole the reason to chose Rust over other compiled languages in the first place: when you need safety over everything else, no matter what. Otherwise why would you chose it? Because it is trendy? Because your fried told you it is cool? That is not a reason enough, even if you write software for fun.
There's two kinds of safety violations, "I shot myself in the foot" and "it's someone else's problem". You don't fret over every library in C either do you, you generally assume that curl or something is reasonably written and tested and does what it says on the tin. It's someone else's problem. If you don't want to shoot yourself in the foot, Rust is a reasonable choice. But to achieve less friction and better integration, less overhead, less effort, you can be inclined to use Rust native libraries. How they remain safe, whether by language features or by other means is "someone else's problem".
I mean I feel sympathy for a guy. A project you started on your terms and had fun working on it. Suddenly it starts feeling like a job and you don’t get paid (correct if I’m wrong.) Arguing with people who don’t get your point in an argument. I understand you should be able to explain it if people don’t get it. But I guess there is a limit how many times you want to explain something.
He isn't getting paid, yet most of the people attacking him were getting paid off of his work. It's pathetic.
@@rich1051414 Isn't that the problem of most open source free stuff. Dedicated people share their code, get nothing in return, while those who use that code make the money while demanding that every software be open source so they can use it to make even more money without having to pay for the tools they use.
that's how all big open source (community driven) projects work
so him being an asshole for a single comment is not ok; but Torvalds, the prime example of an asshole, can constantly do this crap. Double Standards.
I like how in Clojure now people are beginning to donate to people working on good libraries. Not sure if others are doing the same now but it’s a great idea
Actix drama in a nutshell::
Rust community: You cannot just use unsafe code and not even marked it as unsafe.
Actix dev: ha-ha, mutable references to immutable data go brrrrrr.
mutable reference printer go brrrrrrr
I laughed so hard, I love those memes.
The whole point of unsafe is that you have additional knowledge and requirements that keep your code safe that the compiler doesn't understand. They never once provided him with a test that showed UB, but kept insisting on changing internal code to remove that additional knowledge requirement. That's fine and probably a good idea when there's a large team behind a project and you expect several people to be able to modify code and not worry about UB, but since he was solely responsible for the project, he had all those requirements internalised, and saw every such PR as a personal insult akin to "you don't know what you're doing, you'll forget how this works, you'll shoot yourself in the foot", etc. Just two incompatible points of view, exacerbated by a large amount of similar PRs.
Best comment.
I want to make this clear because people in this comment section keep getting this wrong. In Rust, code that says it is safe but isn't is incorrect code, you are violating the language's rules. That is not just a design decision the way it is in other languages. The problem was not that unsafe was used, nor that UB was possible. The problem was that the public API (even if internal) was marked safe when it wasn't safe at all. If that function had been marked unsafe, there would've never been a need for those PRs.
Agreed. People are replacing it with safe code because they can't think about writing bug-free unsafe code. It takes a lot of knowledge and then some courage to do it.
@@Treeniks just started learnng Rust and its definately great language which draws my attention, but there's just so much Zealots in the community, "you can't do that", "you're not supposed to do that", "thats wrong" - and this is what happens with actix-web.
programming language is just a tool to build something, if the compiler or the machine process allows you to do what you are doing, then who are you to say "that is wrong".
Rust is great, but a lot in the community is behaving like a CULT which you must SWALLOW what they want you to swallow.
at the end of the day, the code is compiled into MACHINE CODE and any DAMN language does not even matter even so for the people who'll be using what we are building.
"Unsafe" code is supposed to be used for inner implementations to give performance or features. This is why "unsafe" blocks exist. And the features that were implemented here aren't even called outside the library, so there's no way for the user to cause it to malfunction. TLDR: He used unsafe blocks to gain performace, which according to Rust's docs is an acceptable use, in an app centric on performance.
That wasn't the problem. The problem was that he used an `unsafe` block in a function, but the function was marked as `safe`. However,the function wasn't safe at all, exposing unsafe code behind a 'safe' interface is _not_ valid / acceptable for Rust. Safe rust code could segfault if they pulled a reference out of the object and then reset the object, as shown in the example. If he wanted to leave-it as-is, he needs to mark the function as unsafe so that callers need to wrap the call in unsafe.
The separation between inner-implementation details of the library, and the "user" of the library, makes sense if the library is written in C++, and the user is using it from Rust, because doing unsafe things in C++ is legal. But actix wasn't written in C++, it was written in Rust, so he too is a user of the Rust language and needs to use the language properly, which means wrapping unsafe code with unsafe blocks and exposing safe interfaces, which he didn't do. Otherwise it's just not Rust anymore. RedoxOS is written in Rust, that's the point, and it uses unsafe{} in rust properly, only marking functions as safe if the internal safe code cannot be abused.
@@npip99 I kind of agree: I think the function should have been marked as “unsafe”. Though I kind of understand why it wasn’t too. It was only unsafe if the “contract” of the function was broken. This contract wasn’t implemented in the language (unlike the contract of e.g. Rc), but I don’t think it needs to be when it comes implementation details.
@@npip99 Excuse me? This is what the official rust book says:
"To isolate unsafe code as much as possible, it’s best to enclose unsafe code within a safe abstraction and provide a safe API"
Maybe I didn't understand your point?
I think the issue here is the way the dev responded to this, just "no fuck off" and closed a potentially good solution. Just because you can use Unsafe{} doesn't mean it's completely okay to (or that you should) use it.
The dev should have discussed this further with the contributor instead of being a jerk.
EDIT: Okay i thought a little more about and I don't know, I don't agree with the "OSS is toxic" thing, I think if you are maintaining a oss project you should expect to have issues from anyone on the world, this is hindsight so idk
@@CHE6yp You are right. Even the standard library encapsulates unsafe rust inside safe rust and looks as safe rust to the user.
Rust causing more drama than JS open source community?!?
Never would have guessed
rust community has more energy to fight these wars as we JS developers are already fatigued.
@@AmanNidhi please, one more dependency and I'll go to sleep, I promise)))
@@AmanNidhi Amen to that!
@@kennethdarlington please await and async about it one more time
I think Rust as a great language but the community is mostly composed of fanboys, Rust is the superior language, the design decision of all other languages are always wrong, the only language that gets things right is Rust, everything must be rewritten in Rust, even thing where it doesn't make any sense at all.
Quite frankly, the author should have said: fuck off, I will rewrite this in C++ and deal with it. Undefined behavior is not always bad...
Hey, I'm completely with the old maintainer.
I'm so pissed rn, I'm literally going to learn rust just to use this library
+1
Did you really learn
Did you really learn
Did you really learn
Did you really learn
i feel bad for the maintainer. he probably loved working on his project at one point and then it became too stressful. i dont think its fair that everyone was pressuring him. the point of open source is if you see a different vision for the project then fork it and continue. the community was feeling too entitled imo.
@Ryo Sanada I honestly amazed by the fact you could separate between "mean people amongst a host of reasonable people".
either you're stupid wise, or you're guilty of it yourself. or maybe just naive.
@Ryo Sanada now I'm amazed that you think you're being reasonable :)
It's not entitled to expect defined behavior in something implemented in Rust. There's no point in using Rust if you're going to defeat its safety features. It's inappropriate to lash out at people who volunteer their time to eliminate unsafe behavior in a Rust project for an absolutely minimal performance impact. His ego got in the way of other people's security. Moving the project to his personal account was beyond unreasonable; it was deliberately breaking other people's code just to be a dick. The community was justified in responding with hatred.
@@JB52520 He could have never released the project in the first place or never made it open source.
Bitching at someone because the work they did - for free - that you are exploiting, because you don't like how it is implemented - to the point they evidently have a nervous breakdown because of it is OK... Why?
If you depend on someone else's work when that person had no obligation to let you use it in the first place, complaining when they get stressed out by endless demands from strangers who tell them you're doing it wrong is, frankly, petty and entitled.
If you don't like how a project works, don't use it.
Nobody forced you to.
Oh, but you chose this particular library because you liked what it did, but now you're bitching at it's creator about the very thing that makes it function the way it does being 'wrong?'
Ultimately this is the kind of stuff that risks killing the open source community.
Why open source something if you know doing so will get you endless grief?
@@JB52520 Protection from UB that is not shown to be able to occur (via, as the maintainer asked for, a unit test using the public API) is going to be a low-priority fix *at best* for any maintainer - as it should be. The first, overriding principle in software is that it does the job. Was actix broken? No. Might it have been? Sure, but the submitter didn't show a practical example, only a strawman.
Rust's safety guarantees are not intended to be the overriding concern. They are only a tool *not the goal*. And given actix's position vis-a-vis speed, the submitter should also have submitted a comparative benchmark showing the effect of the change - since the change wasn't otherwise fixing an extant *bug*, they should have at least shown that it didn't make things worse. Minimal changes are not null-changes, and an accumulation of seemingly insignificant inefficiencies can add up.
Could the maintainer have been more civil? Perhaps. But the submitter had no special rights here - the maintainer put orders of magnitude more work into the project, and deserves orders of magnitude more deference with regards to it. I would expect no less on any project.
Ben, you are possibly ignoring a major fact: he is NOT a native speaker of English. Moreover, written communication is hard; even for natives. Couple these facts with the lack of empathy and straight-out entitledness, and you'll see this drama in a better light.
Because in the end, despite our earnest efforts, we're humans and not coding machines.
Big point, he probably didn't have the best words to convey his mind happens with the best of us
You can be polite, even if you are a non native speaker.
Imagine open a PR and get slapped in the face, this what these replies sounded 🤣
@@enzo.albornoz I think for someone who speaks the language non-natively who has not been immersed in the surrounding cultures, their tone can quite often get misinterpreted as rude in my experience. I suspect that's what's happened here as well
as a non native speaker, i kinda feel the pain. i have trouble choosing the right word to express what i meant. internet being internet, everyone automatically assumes the worst.
lol, new maintainer is a time traveller
Steins;gate?
@@dhanushc5744 John Titor from Steins;Gate is inspired by "real" John Titor who "traveled in time". Go to read about that.
He has seen the future and came back to PR the final version
@@exactzero Well, usually it is future dev that has to deal with past dev's shit, good to see a change for once.
I think he got the name from Steins; Gate anyways. Just a guess based on he having an anime pfp
Interesting how everyone didn't realize what they had till it was gone.
That's what forks are for. You think your design priorities are better than the original project's author? Fork and demonstrate to the community the benefits of your vision.
The second patch changed nothing about the library, it just made the internal code safer and easier to collaborate on.
Please god, don't fork a project used by lots of people unless there's a fucking amazing reason to do so, or it's just for your own use.
This particular issue was clearly no reason to fork the entire project.
Why would forking be bad for small changes?
@@Christobanistan eh
@@mateowang6570 if it's for your own use, there isn't really. The issue is if it starts to fragment the community, more choices isn't necessarily a good thing for users, particularly if there is no clear reason to choose one option over another. Also is work maintaining your new fork the best use of those resources or would that effort be better spent elsewhere (such as contributing to the original). That's not to say you should never do it but you really should have a good reason.
For the rust newbs..
unsafe is a helpful tool.
It's a signpost to say that basically, you know what you are doing.
You can wrap that unsafe code in safe interfaces. This is the point.
Unsafe blocks don't make unsafe code. Particularly if it is wrapped up in safe interfaces that guide consumers on how to use it.
Unsafe isn't "BAD" either; it's simply a tool. Use it, but make sure you know what you are doing!
Unsafe is basically announcing "I know what I am doing, and if something breaks it is entirely my fault."
“this patch is boring” i laughed so hard i almost peed my pants
Last words of a burned out programmer....
if he sees linux kernel prs
Just to clarify, actix is not dead and actively developing and Its still amazing framework 👍🏻
👍🏻
@@ゾカリクゾ 👍
Just UnSafe ?
While I agree making the repo private was a bit heavy-handed, any company depending on the code that didn't keep a copy locally was just asking for trouble. I know at my company, we use quite a bit of open source software, but it's all imported into a private company repo first, from which we pull the code into various projects. That way, if the public project disappears overnight, we have all the source and artifacts in use up to that point.
Smart!
There are 2 fundamental reason why actix-web ended up like this. Firstly, it was too good performance-wise. Secondly, it broke the 1st Commandment of Rust - "Thou shall avoid 'unsafe' at all costs".
It was not going to last.
Imagine, a solo-dev with no prior stripes to his name made a web framework that trashed everything that came before it on TechEmpower's ranking charts. What's worst, he did it by using Rust and breaking its 1st Commandment of writing Rust-ic code -- 'unsafe' everywhere. Immediately after actix-web was crowned #1 by TechEmpower, everybody started to go through his code character by character. That is why everybody in Rust-land knew his code better than him, that is why they were pointing at non-pub functions.
I even remember a discussion on HN on something related to web servers and someone causually mentioned "actix-web". Then immediately, on each refresh of the page, you saw new replies popping up saying the dev of "actix-web" was cheating his way to the top by using 'unsafe'.
This was a death by a thousand cuts.
Also, notice there was never any talk in the Rust community of forking "actix-web"?
lol, is rust like a religion? the 1st commandment of rust...
@@Jossnaz You'll never find another community that preaches the conventions of the language more than Rust.
@@Wzymedia well I cannot judge. But having preachy people all over the place sounds kind of horrible to me. But I dont know the real situation. You know, using unsafe code to have a fast service doesnt seem necessarily wrong to me and I wouldnt call it cheating either. "Use this server with a lot of unsafe code and you get fast performance" sounds absolutely fine to me.
@@Jossnaz if you look at the PRs for the fixes of 'unsafe' you'll see it would be rather easy for any of these "fixers" to fork the project and fix it, but no, it was far too easier for them to stay one side and critize the maintainer.
That's a stupid commandment, really. I think Rust being split into "safe" Rust and "unsafe" Rust is one of its biggest strengths.
However, to be honest, I saw this one coming from a mile away. The second you make a decision where you sacrifice performance for safety or vice versa, you'll have people tear you apart because half of them ain't gonna agree with what you did. And the "unsafe" keyword only makes this decision stand out like a sore thumb in your source code.
The "this patch is boring" message was in a response to someone who
1. Showed that you can cause undefined behaviour from the public api
2. Provided a patch to fix it
That response was IMO totally unreasonable (as many other maintainer's responses anyway).
I am kinda sad that this got widely interpreted as "Rust community roasting maintainer for using unsafe", while the problem wasn't really the usage of unsafe but maintainer's attitude and people getting upset because of it.
Also for comparison - that issue was one of the many unsafe related issues that author opened on various repos as a part of work on his article. All those projects responded in some reasonable way, whether they did something about it or not, except for actix, where the maintener went straight away into defensive mode without any meaningful response.
So what? There is UB but UB is not always bad. It could be that you will never encounter that UB with a sane use of the library, and in contrast resolving the UB will probably mean a performance penalty. Rust unsafe is also a way to optimize code, if you know what you are doing. I use unsafe a lot because I know what I'm doing, damn I wrote code in C and C++ for 30 years and nobody questioned about the fact that is super dangerous I should not do that, and now in Rust is a problem? I know how to write code and thus I use unsafe when using it does make sense, even at the expense of some UB derived by an incorrect usage of my code.
@@alerighi You're right. I am not arguing against that. As I said, the problem was maintainer's attitude, not unsafe code (or UB).
@@panstromek I dont think maintainers attitude was a big problem but the communication. I understood what he was trying to say and I see that majority of the programming community wont understand it because the way he wrote it. If he would had spent more effort in explaining his thinking it would not have exploded the way it did
There was definitely dog piling on the maintainer. People seem to hate actix with a passion. The amount of people declaring 'i will not use actix!' seems bizarre considering how much software I personally do not use, on the daily.
The first bit was helpful the dogpile not so much.
11:52
he's also the guy who created the flask framework, so it's good that someone with web framework development experience is coming aboard.
"someone who works at sentry" --- that is Python Royalty you're addressing sir
😂
Yea @mitsuhiko is very well know in Python community. Creator of Flask microframework.
man this was gold. LMAO
As a C++ programmer, I don’t get the idea of fighting UB in unrealistic situations
This is major conflict between web only programmers and traditional native programmers.
TL;DR I find too many programmers are used to writing in managed environments without ever having to learn to manage memory themselves and it leads to inexperienced devs expecting a tool sort out all of their issues and expect modern hardware to be the answer to poor optimisation. -- Bit of rant below
I'm actually a rather young developer, originally self taught up to the point I went to university, thankfully at that time we still had a lot of old school professors who wrote in older languages and a solid understanding of how things work at the very lowest levels. One of there ways of teaching us to write good code from the get go was to make us learn assembly and write programs in assembly, it was never about learning assembly but it was to instill in us how to write code that was functional, well written, how things work at the lowest levels and to make sure we properly understood memory management and concepts around it.
I see far too many self taught programmers taught from online courses that are more often than not made by people who've never learnt to program out of a managed environment with a huge toolchain that will make sure you code is almost always going to have behaviour that's expected or will even fix bad code for you. I personally don't think this is a good way to learn to program, yes the tools are useful and once you've got the experience and skill to write decent code without assistance you can use these tools but you should never rely on them.
Programming is something you only get better at with experience and with trial and error, when you're being handholded through the process and relying heavily on manage environments to make sure you don't do anything wrong you're not learning anything other than to write that one specific thing in the safest way possible that the setup guides you towards, it does not provide you with ways to experiment with more error prone code (unsafe code is not unsafe, it just means it has a higher chance for things go wrong if you're not careful) to make something that runs faster or has more flexibility.
Those are the ppl who follow tutorials and think that they are programmers without ever trying to build their own project.
@@catmaxi2599 im in college doing c++ and i pray i don't end up in a job doing Java
@@KeraLab C++ expects you to know what you're doing. Neophytes need not apply.
Exactly. Bro, these new languages have ruined people's brain.
People think they can write anything and compiler should do the rest. People don't have brains anymore.
Maintainers can learn a lot from this. It’s ok to say ”I’m not motivated to review this”. You should be clear but polite.
The hard question is how long you should keep a PR open if you know you’ll never accept it. People get bummed out when you close it too fast - but as a maintainer it’s nice to get rid of unnecessary open PR:s - and by leaving it open you could give them false hope.
A solution would be to be honest you are considering closing it - but let the creator respond.
I think what ticks people off is when you close PR:s instantly after a brief comment as that seems rude and rushed.
be like typescript, dont respond to PR at all
or they can just go "i don't approve this pr just because, feel free to fork it"
When I read that "I must be braindead", I'm getting the vibe of him feeling insulted.
I don't think he thought about others. Internal to him means, he has oversight of any changes, thus UB in internal code must mean that HE missed it.
You are wrong. Internal code means, no body can mess with the code, so there is no way that UB can be produced with the code. Actually the PR UB demo code was created by a brain-dead and supported by other brain deads. Unfortunately they didn't even understand the meaning of the comment, 'I must be braindead'. Such a shame.
@@NowHereUs exactly
@@NowHereUs internal code can also be referred as "unreadable code that I hope that works" 🤣
@@enzo.albornoz It was readable. It was just a private piece of code with no public interface. Did you not notice the name 'DateServiceInner'.
I imagine the most frustrating thing for the maintainer are all the PR's that don't actually SOLVE PROBLEMS but just rewrite the existing code. I also hate that people encourage this, I have seen youtube videos about "How To Contribute To Open SOurce" and it tells you to start with something easy, like doc typos or in this case, randomly refactoring unsafe stuff. If you wanna contribute to open source, find a project with an active bug tracker or TODO list and start there, not random improvement suggestions!!
I can't stand those kinds of videos: they encourage new programmers to contribute to a project just for the sake of contributing to a project. If you want to contribute to OSS, that's great - contribute to a program that you actively use and understand. Strolling around someone else's codebase looking for things to fix or add is just going to cause friction like the pull requests in this video.
ice cold take: there's nothing wrong with correcting doc typos. it makes things more searchable, helps with people who use screen readers, helps nonnative readers of the language, helps anyone with visual processing disorders, and gets people at least used to the process of how PRs work
I'm not gonna comment much on refactoring because that's case-by-case - i think it's something that inexperienced devs do more often BUT there are definitely times when refactoring improves readability and maintainability.
I wholeheartedly agree that fixing unsafes is petty. Real programmers should be fixing bugs after users experience them, and cause damage, not before
@@polimetakrylanmetylu2483 agreed, the change is on "private" part of the module and nobody will use it like example without deliberately placing such case on the actix codebase itself.
it's like complaining about an unsafe door on top of locomotive that people can climb out with a ladder (that shouldn't be inside when the train is running) going up and smash their head to one of the narrowest tunnel that the train will go through only when the main railway and the secondary railway is on maintenance which is super rare. and the proposed fix is removing the warning sign on the door and weld the door. and the old maintainer does not agree because the door have a legit use on maintenance or smth.
Sometimes problem solved is lag. But yea random refractors (that will possibly only add lag) make no sence.
I don't think this was just because of this incident. It's probably because of the general pressure and stress that piled up overtime.
I'm frustrated that this video again perpetuates the idea that this was about unsafety existing at all. It wasn't, and people keep using this to perpetuate the insanity that Rust's mantra is "Avoid unsafe at all cost!". That mantra doesn't exist.
The issue wasn't that unsafety existed, it was that it was hidden. When a function in Rust is unsafe it needs to be marked with the "unsafe" keyword.
It doesn't matter that it was internal code because the unsafety mechanism exists to remind the developer that an operation may be unsafe, that includes maintainers of internal code.
The solution to this would have been either to fix the unsafety issues, or mark the code unsafe if the developer doesn't want to introduce a performance hit. The developer here refused to do either.
Thanks for adding more context.
But if Rust is all about safety how it allowed to compile an unsafe code without marking it with 'unsafe' keyword in the first place? Isn't this defeating the purpose of unsafe making it optional keyword?
@@ke5uq1we8h The compiler does require unsafe code to be marked unsafe, and it was. It was using unsafe *blocks* inside of functions, and not marking the *functions* themselves with the unsafe keyword. So callers of the function wouldn't know it was unsafe under the covers. Rust doesn't require every caller to be marked unsafe because a code block somewhere in the program is unsafe, that would be silly. It only requires callers to be marked unsafe if they call a function marked unsafe, that's why people were asking for the functions to be marked unsafe and not just code blocks inside.
@@MonkeeSage So, unsafe block of code inside a function doesn't render that function unsafe, but calling an unsafe function - does. That is, an unsafe function will drags its unsafety all the way up the chain of calls until an unsafe block of code, which effectively stops the notion of unsafe code from spreading. In my opinion, Actix developer fully meets the language rules by concealing unsafe code inside a block according to said language rules.
@Layl Bongers Your comment shows a clear lack of understanding of how unsafe code works in Rust. Take a look at ua-cam.com/users/JonGjengset - specifically "Porting Java's ConcurrentHashMap to Rust" - a 3 part series @MonkeeSage is bang on the money.
I can say that open-source can be extremely frustrating from the contributor end as well. Having maintainers just turn their noses up at contributions that you made in good faith and poured hours of your time and effort into is disheartening, to say the least. I've stopped contributing for the most part, I just modify things for my own needs.
Agreed, that kind of behaviour just results in code being forked and maintained by someone else. That works - but nobody wants to have to pick between 5 different versions of a single codebase. Taking personal offense to contributions is unhealthy for the community.
“Something we’re gonna see in open source projects that’s gonna happen from now on”…
Open source software has been around for almost 70 years. This type of drama has been happening for at least that long. It is certainly nothing new.
This is where I think we can also learn from the Rust project itself. A clearly defined set of philosophy and processes can help with these decisions quite a lot
This reminds me of the left-pad issue. I honestly hope this happens more often to get people to realize that depending on github repos and npm packages is not always the best decision for every dependency. Personally, I like to put the frozen code dependencies directly into my projects in certain circumstances. It's not always feasible, but in hindsight, adding code of left-pad would have been way easier to deal with than the broken dependency when the maintainer removed it.
the most notorious dependency crash ever. That kind of crash would not happen under Rust though, as cargo does not operate in that fashion.
@@simonfarre4907 could you explain more?
@SLKA a bit late, but bad versions of cargo crates are yanked. You can't get yanked versions into new projects, but if you have project with yanked version it remains there in working condition.
I think you should change the title now that actix 3.0 is out; it may discourage people from using it
Thankx I was discouraged actually
Those people would give up halfway through either way. If a title of a video turns you off something you want... You don't really want it.
Try to open a PR to Ben about it /s
Lesson: it's dangerous to make unsafe pull requests. Thanks for sharing, Ben.
What I learned from this is : everything can or can not be unsafe depends on how you use it. Like that you are supposed to use soap to wash your hand instead of eating it.
If you don't use unsafe it won't. Your statement is only valid when you use it. The main advantage of using Rust is to be fast and safe.
I am a 2-year old, if the Soap smells like strawberries, I am gonna taste it...
over 52 year old... ?
I won't comment on the human aspect of things, but let me clear up something about the technical side:
Rust's guarantee is that, any code that isn't in an unsafe block, is safe and always well defined. When writing unsafe code in Rust, it is your responsibility to either make the public API unsafe as well, meaning the caller will know your code can cause UB, or make sure the API is 100% safe to the outside and UB is impossible. In Rust, this is not a matter of internal vs. external code, it is a language guarantee that must always hold. Rust is not C++. In Rust, UB in safe code is not a design decision, it is incorrect, you are violating Rust's safety guarantees and thus violating Rust's rules. Unsoundness in safe code is incorrect Rust code. Again, this is not a design decision of a project, it's part of the language. I get how this may seem strange or limiting to the outside, especially coming from other languages, but Rust works different. Even if it is internal code, if one can achieve UB in safe code, that is a bug by Rust's definition and should be fixed 100% of the time, no exceptions.
then why does the compiler let you do it?
@@LC-hd5dc I don't get your question, why does the compiler let you do what?
C++ and rust agree that a program is not well formed if UB can occur at runtime (safe, unsafe regardless). But you are making a stronger claim: that it is not just convention but a language guarantee that safe code could never possibly cause UB no matter how it is written (and you need this to be not only convention but a language guarantee in order to say that this is a "bug by Rust's definition and should be fixed 100% of the time, no exceptions"). Is there actually a rust language spec saying a program is not well formed if, after possibly replacing the program with a different one differing only in the safe sections, this new program can cause UB at runtime?
To my knowledge, the only existing spec for rust is rustc, which does not prohibit such programs. That leaves this norm as merely a (strong!) convention for writing rust. There are conventions for writing many languages, but failing to follow those conventions is usually not considered a bug. The program possibly misbehaving is a bug. In any case I agree that open source libraries should follow the strong conventions of the language, but I think you are overstating their transgression.
@@austinconner2479 It's been a while since I wrote that comment, but if you write safe code only (i.e. don't use any unsafe blocks) then Rust guarantees you that no UB can happen. If rustc still causes UB, that is considered a bug and an issue needs to be opened. It's the same for the STL. Rust's whole design revolves around that idea, so it is much more than just a convention. You are right though, technically rustc is currently Rust's spec. But again, safe code causing UB is considered a bug in rustc's terms. Other than that, there is a Rust Reference book and although it is explicitly not a language spec, it's the closest that we have currently.
The Rust Reference book states about unsafe blocks: "When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context" which I interpret something like this: When you write an unsafe block, you are signing a sort of contract with the compiler that your unsafe block will not cause any UB in it or the surrounding safe code. If you violate that contract, rustc is allowed to do whatever it wants.
Of course rustc won't prevent you from causing UB in safe code through unsafe blocks, the point of the unsafe keyword is that the compiler cannot check if what happens in it is actually safe. But rustc still expects you to uphold that contract.
My wording might've been a bit extreme in my original post, however an unsafe block that causes UB in other safe code should absolutely every single time be considered a bug. It is certainly much more than just a convention and the Rust community will tell you so, as what happened with Actix Web.
As a rule of thumb, assuming you know what you're doing, don't let user interact with unsafe block and you're good.
And the John Titor mystery deepens. Maybe actix-web unsafe code has something important to do with IBM 5100.
Just stuck in 2005
The only thing I would change is mark the function as "unsafe" as that wouldn't affect anything except the need to mark the calls as unsafe.
I think that "so example assume I'm brain dead" means he wants an example of usage explained very simply
reworded i think more like "example plz, i'm brain dead" (have no idea about the thing, can be non-offensive phrase in some language)
I thought that meant only if he was brain dead he would use that PRIVATE CODE that way.
I found myself on the side of the maintainer multiples times, except when he removed the repo (greasy BS, just stop approving PRs). I could be totally wrong because I've never used Rust and don't understand the interpreted languages switch comment, but:
1. The issues only arose when people were using non-public, internal functions. Anyone who had been using these unsafe functions and getting away with it to this point (would || could) now be screwed with these PRs. If that's the case, they should have forked and made a 'safer' version of actix.
2. These issues are very unlikely in production and thus 'boring pr' rings true.
Didn't they also prove there was undefined behavior outside of using internal functions though?
In response to your first point: in rust, it is impossible for library consumers to call internal functions. They cannot bring then into scope. Same goes for types, macros etc. All you get is what's been explicitly marked as public.
Eh... Rust is mostly meant to not have all the shenanigans that are common in C code.
Which in C, the libc and stdlib libraries are actually a vector to break into a computer. Particularly through the printf syntax that can be used to break stacks and run arbitrary code. It requires a lot of ground work and study--and breaking in this way _will_ show up in log files... and most computers will have daemons running that can be all, "yeah... something is doing some FUN with libc/stdlib"...
... but Rust is meant to be a bit of software that can run without a daemon making certain other software is playing safe with it.
So even if a routine is internal and not public--that doesn't mean it cannot be used as an attack vector.
Hell, tar(1) has had (very specific patch level) versions that you could get root access to a system via timing a racing condition properly when the extracted files are being given permissions on the file system they are being written on. An exploit that--nobody really knows how to do--except making two people in the world... but Tar still got patched regarding that. Mostly to keep it that way.
So... I understand why Rust would want to have these lofty goals... and I do think these goals are really lofty and Rust hasn't gotten them... but it is nice to see what happens when they are attempted. I just wish Rust's community would stop acting like they've gotten there already.
@@NimhLabs you're absolutely right that an unsafe internal function could be used as an attack vector, but in order for an attacker to reach it, the consumer code also needs to be broken to the point of allowing a user to call an arbitrary function pointer. As long as the consumer only writes safe rust, and we assume no exploits are present in Actix like the author wants us to, it won't be any more an attack vector than any other piece of code on your device.
That said, I hope I'll never need so much web server performance that I need to blindly trust code written with the Actix philosophy.
@@iwikal Are you suggesting that Security Through Obscurity is completely fine?
Also... with exploits similar Shellshock happening maybe about twice a decade, the issue isn't so much the consumer writing code.
That being said, I don't think Rust has completely gotten to where it wants to think it is with its Safe code philosophies... but I admire that they are making an attempt. The Rustlang community seems to be full of people who smell their own farts.
Seems like the root cause of the problem is that open source needs maintainers in the first place. First of all, no one is entitled to a repo owner’s time, and the “implied contract” of open source that one of the GH commenters mentioned is not actually a thing. Open source means you can click the Fork button and do what you want. It doesn’t mean community development, and it doesn’t mean a project owner has to maintain a project in service of a community.
I think what open source needs to permanently solve the maintainer problem is a trustless and participatory mechanism for determining consensus. Basically a low-friction and very efficient or automatic way of “voting” your use of the project in favor of, say, removing unsafes or aligning with the original author.
also, fragmentation/ variants is a welcome thing most of the time, not all solution will work out the long term, having multiple variants means the better solution will prevail over time or an external change (new compiler features, etc) will make the the split unnecessary. we had such split that later date were merged like how it happened on node.js and io.js split and merged later on.
Undefined Behavior exist in several other languages as well, not surprisingly C and C++ included. But it's not necessarily when you corrupt memory, it can invoked from a lot of different behaviors.
came here again... Actix web is more powerful than ever before. version 3 is incoming as well
If the author decided to flow the path of unsafe code, and he knew what he is doing, and the project hits the top of performance in benchmarks, come on, stop crying.
Accept the fact that the author did the hard work, that he has a life, family, and don't want to do people's will for (in his vision) nothing.
Be ashamed of this child attitude, fork the project, remove all unsafe code, get community around and move on.
neovim do that and it's all right.
No conscientious developer intentionally releases unsafe code for the sake of winning some perceived benchmark competition. That said, if your use of the code is mission-critical and the maintainer couldn't care less about your mission, you should by all means fork it. You are ultimately responsible for what goes live in your production environment.
@@diggydude5229 In rust "unsafe" only means "unverifiable at compile time". It can and usually is completely safe well defined code, if it is written by someone who knows how Rust works. Unsafe rust is a hell of a lot safer than anything written in C / C++.
Also some people are using "unsound" ambiguously. It isn't undefined behavior like they are trying to imply. It is like accessing the kth element of an n-length array. It is totally defined whether this is correct or not, but if you do it wrong then it will be incorrect.
@@diggydude5229 noob
@@cruelplatypus67 Great input, kid.
Except, I don't think he did know what he was doing. Benchmarks of actix make it look like there are memory leaks.
Good things also happened because of this and I hope people start to be more aware of the effort these guys put on OSS
I have grown to be a big fan of Warp. The filter model can be overwhelming, but once we wrapped our head around it, it is actually very powerful and well thought out.
it looks really good. Rocket is upsetting to me so I'm trying to find a better framework (I came from node/js and I liked koajs/svelte not react/angular stuff). I also wish they'd put tokio into base rust already
@@GrandpaRanOverRudolf Interesting, in node/js we use joajs as well, and it's very clean.
Btw, on the Rust side, I am moving to Axum. It is very well designed, not too high, not too low, and well componentized. Working on a video tutorial as we speak.
In addition to entitlement, it seems people have way too much trust in public repos that can be gone any second.
The irony of choosing a language because you want guaranteed safety. Then taking a dependency you don't have control over
@@illusion466 lol
if they had a PR that means they forked it. so they HAVE the code. this complaint makes no sense lmfao.
I should add that saying "it doesn't even have pub(crate)" is not "it's not pub". It means it's contained within the specific module he wrote it in. Any unsafe code sort of makes the whole module it's in unsafe, because people calling the unsafe code have to do things properly too. That's why you abstract it into a module. What the dev is saying is that he contained it within a module, hence it's fine because people modifying that module should know about the unsafe code within it. He's not even arguing for general additions to the crate to have to deal with the unsafe, because it's not public within the whole crate.
I use rust heavily but I must admit some rust fanbois are one of the worst groups of people in programing world. They have difficulty to understand how real world work and how people work.
I have given up on the Rust community as well. To do anything real, you have to do a lot of ugly unwrapping, Boxing, and other annoyances that makes writing Rust a pain in the ass.
Doing Haskell instead!!!! :D
@@friedrichdergroe9664 I wanted to transition to Rust from C++ about a year or so ago. The community made me resent it. I felt like it always was a cult, praising Rust whenever possible. I mean the language is ok but didn't really have a good reason for me to make the switch.
@@Frozander Yeah, they can have attitude. I wonder if has anything to do with the nasty attitudes going around at Mozilla at all? Or as I like to call them, Marxilla. :D
Any group have those kind of fanboys, don't use this situation as a path to attack the comunity because this behaviour exists everywhere.
@@neociber24 Just because this behaviour exists everywhere doesn't mean it isn't RIDICULOUSLY bad for Rust. There are shades in everything, but Rust most definitely HAS a problem. I'd hands down put them as the worst community of all programming languages. Even the most fervent functional programming fanatic is child's play in comparison to the average Rust user. But then again, this behaviour stems from the very top of the Rust echelon. When your own leaders endorse shitty behaviour "FOR THE RIGHT CAUSE" (big quotes), how can you even expect your users to behave differently?
John Titor lol the "time traveller". Read about him, it was a really captivating story back when it emerged :)
Moral: Donate the maintainer, so he can hire developers. If people have donated him, he could hire some devs...
I can relate to the maintainer here quite strongly. Although i am not a rust dev and don't understand the severity of unsafe i can compare this to 'any' keyword in typescript.
Something completely different but the idea is same. Avoid using 'any' at all cost. But it exists when you have no way to properly define the type for an argument.
Seems like maintainer made sure that there wasn't any ub in his logic still people kept pressurize him (for years) to remove it because of some unwritten rule in rust community or an easy way to get listed as a contributor.
In all honestly, I think the maintainer would've been perfectly within his rights to just say: "Sorry, I'm not doing this." and close the PR.
Yes, he should have done that. He is perfectly right to use unsafe everywhere he wants. It's his project. In the other hand, if you decide to do it so, you also must accept the criticisms, and accept other people saying "don't use unsafe" when you can avoid it. In the end, you control your project.
@@1karaden True, I guess what I'm trying to say is he was perfectly within his rights, but he could've handled it better.
Yeah he was, but it would be better to detail his reasons in a contributor guideline so that people don't end up writing PRs that keeps being rejected for some unknown reason.
This reminds me, thank you so much for your open source work. 😂
Sad to hear about the drama. I've heard so many great things about Rust, it's on my list for 2020.
Rust is still awesome. Actix lives on and is now safer to use.
On top of that, there's other web frameworks like Rocket, Gotham, Warp, Tide, etc.
@@WorstDeveloper - I agree, I'm going over Actix, Rocket, and Diesel now. It's really fast. The type checking and compiling reminds me of TypeScript. Hopefully Ben will make videos on Rust. ;-)
The public APIs were not dangerous. The bugs would have only happened if someone deliberatly used the code incorectly. I wonder if the speed decreased or stayed the same with those refractors.
Thank you very much - we are in the process of going open source with a project. Our community guide lines will include the possibility that a commenter can be banned for not being constructive. Secondly the developers will not be the ones to decide of which comments should be answered or not. Those rules are there to protect the developers from smart asses like all the professional "dislikers" on youtube. Secondly some developers are not born as diplomats.
You are going to suffer. Why do you inflict this on yourselves?
And, have you suffered? Banning people for not being constructive is pointing a gun to your feet.
I personally think that the community's response is pretty natural. One of Rust's core values is guaranteed memory safety and thread safety, and one of the fundamental rules when writing Rust code is that all safe functions (those not marked unsafe) should guarantee them. This rule extends even to internal code, because if people were to inspect or work on these code, they will assume that safe functions are actually safe.
As is shown, this project had several places where the safety guarantee was broken by safe functions. Specifically, the issue at 12:15 cited a piece of code that handed out multiple mutable references simultaneously. This was stepping on the core value of Rust, and of course the community wasn't happy.
Perhaps one reason for all this is that the original maintainer took their philosophy on software development too far. They thought that software development is a creative process, and on this basis, they rejected things that are not creative. This led them to disregard these issues and PRs mentioned in this video, uncreative yet solve a big and very real problem - people who work on the internals of this library may use these internal safe functions as if they were actually safe, but since they're actually not save, potential problems emerge.
There's still one thing that I'm not sure about. Why did the original maintainer outright disregard the fundamental rule of writing Rust? Does it also has to do with his philosophy?
With all these said, I'm not saying that it's all the maintainer's fault. The exchange between them and the community certainly has to do with the outcome.
I find it ironic that the people behind actix-web were having trouble sending their messages to the community actors.
--A fan of their work.
I want to give my 2 cents for this.
Rust is a language that is made to be save and that states as a convention it states that unsafe should be avoided if possible.
I also think that most of the potential problems with the code could be prevented at compile time, if you could tell the compiler to fail on certain patterns that dont really make sense.
I think that the maintainer could have handled this by explaining and not rude comments.
dude was burnt out i think it was too late
At 7:13, I think the maintainer means "Give me an example of what you mean. Assume I am brain dead." Or "Give me an example and explain it like I'm five"
It's more like "Your example assumes I don't know what I'm doing" because it was internal code that only he would have written, but he wouldn't write unsafe code like that, because he isn't brain dead (I'm just assuming).
We send rockets into space without complete memory safety..... People are out of their minds about some things.
This is like drama in the code community. There could be a whole reality tv channel for this kind of content. People would love it
this reminds of the notorious left pad accident in node community :(
Is there any link describing the issue?
@@temirzhanyussupov6997 here you go: qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/
Temirzhan Yussupov blog.npmjs.org/post/141577284765/kik-left-pad-and-npm -> one from the npm blog
This reminds nothing of that though. Because NPM/node's package management does not work like Rust's Cargo does. You literally could not achieve the same situation under Cargo. which is why people love Cargo. Because not only is the system versioned incredibly well, the compiler toolchain is also versioned - so let's say a project dies, and stops working under newer versions of rust, breaking compatibilities or whatever, the toolchain itself can easily be used where those things are compatible. This is not the case with Node and NPM either.
The lesson here - set clear rules for the community. Then you can refer people to the rules when they don't respect them.
Complaining about people not "reading the docs" in the case of actix is pretty rich. People might read more of the docs if they actually existed.
It's weird to see people's takes on this especially people who don't know Rust.
All of this seems like it could have been solved by sitting down with the original maintainer and telling him how unsafe works, how to label it and why UB is bad.
He did not need to remove all unsafe, just label it correctly. If he wanted to make sure it was fast then he needed benchmarks between safe and unsafe. Rust safe can be faster then Rust unsafe.
He seemed to be very much in the wrong as having any Compiler UB is not ok even in internal code. Even worse for Rust since it optimizes based on language garentees.
UB can manifest in many different ways from different compilers to architectures. You do not need to call the function with UB to even see the results. UB can cause incorrect compilation making bugs almost impossible to fix or track down.
Thanks for retrospect the facts and giving suitable comments.
New to rust as of today. Kept pausing your video to read reddit and github about this problem.
Still debating actix, rocket or gotham for web api. Comming from node, all of them are faster anyway so I don't care about benchmarks "cheating".
On the topic of "unsafe".
The maintainer outs himself there: "Maintainers must know how everything works."
That isn't a scalable situation, when projects develop, eventually nobody will know how every part works. This is why we use abstractions, and why things like unsafe are a problem even in internal code.
Seems like there was contention between this project being a fun project the maintainer built for one thing and it being a production scale project that it grew into.
it's his code, he's not being paid by some big corp for it. He does it on his spare time. Also "unsafe" is complete nonsense. C/C++ has been doing this since forever and they don't have a problem.
i dont understand, why didn't he just close the issue and ignore them? Like if they want to program with a different ideology why cant they just fork the project and continue there?
Still using it for small prod graphql server.
I can kind of understand where this guy is coming from. I think the conflict arises from a misalignment of interests between him and his users.
I think I would characterize him as a sort of speedrunner type of programmer. First and foremost, his interest is in pushing the bounds of what can be done with optimization to make a web server run faster, and everything else, be it safety or usability or any other beneficial characteristic of software comes second. If it doesn't help speed, it's not interesting. If a suggestion is detrimental to speed, he might find the mere suggestion to be personally offensive.
On the other hand, the community are business programmers, the sort of people that would actually use a fast web server in production. Their primary concern is the bottom line. They want speed insofar as it reduces costs, but any sort of risk of undefined behavior whatsoever also introduces liability, and reducing that could even be a higher priority to them. So they want provable correctness, even if it costs some speed.
Now what I would say is that maybe, if you're one of the community members, perhaps this project is not what you're looking for, though perhaps a fork of it maintained by somebody else might be.
The unintended behaviour did not happen when using the public APIs. It happened if someone forked the code and did something bizzare in private code (and also tied it up to public API)
Feel bad for the maintainer, probably had well thought out reasons(tests, benchmark maybe?)for using unsafe then being asked without tests, benchmarks to change code by "Jonny Whoknows"
Have done the same document request , merge & prepare to throw Jonny under the bus!!
Your video title is more destructive for Actix Web rather than the maintainer giving up. More people will come forward to maintain. but if anyone watches this video before starting a project, he might not use this framework.
This somewhat reminds me Golang community where every newcommer is asking for this or that feature and what not. If they would implement or merge every PR ... the language would become total garbage. So there should be heavy censorship. Same there. He is the author with his vision. He is kind enough to review the PR. Somebodies ego is hurt by his attitude. Somebody wants him to be soft and nice. I totally understand that guy. If somebody wants to eliminate Unsafe he is free to fork and work on his own. No reason to make drama.
That's true to a degree. Actix-web is an amazing project and the author is a brilliant programmer..BUT the use of unsafe can very controversial in the Rust community. It's a kind of necessary evil. Too much unsafe begins to unravel the entire idea of Rust's safety guarantees. It was a legitimate concern and the author's position of "I know what I'm doing" isn't exactly reassuring. Having said that, there was a lot of unreasonable hate directed toward the author of a fine project.
@@ryanleemartin7758 Rust is a failure.
@@coshvjicujmlqef6047 Seems to be doing pretty well from my point of view.
@@ryanleemartin7758Total failure. unsafe all functions? lol
@@coshvjicujmlqef6047 unsafe all functions? what do you mean by that?
FYI, "John Titor" is the name of an alleged time traveler who famously used to call in to the Art Bell show.
I'm still using it. Even if it stays unmaintained, it still does what I need it to and until something better comes out I am not willing to change just because at the moment it's not being maintained. Even if no other changes happened unless some framework was considerably better I will stay with actix because its freaking fast and very elegant. I think the maintainer of the project felt very insulted. He makes this amazing server and because someone else doesn't understand how things are working in this framework on a very low level he decides to just make a bunch of changes, not based on fact but on theory, doesn't benchmark his changes and then demands a pr. Yeah I'd feel frustrated to say the least...
Dude, the "someone that works at Sentry" is none other than Armin Ronacher, the austrian Python legend :D The father of click!
The problem with the people complaining is that they are using/thinking about the "safe/unsafe" idea completely wrong. You have safe and unsafe code, because you wrap your inner workings of your library (which is why he keeps talking about it over and over that it's not in "pub(crate)") meaning, those functions or types, are not exposed on the API boundary. You *can't* call / shouldn't call those things from the user perspective of the library. You can only call that, if you are doing *internal* work (meaning; you are working *on the actual* library itself).
18:22 the plan is in motion. the next step is to get actix web running on an IBM 5100.
The title is very misleading. I wouldn’t name it that way for the content you provided. The content is interesting though but nothing to do with the downfall of the framework, at least to me 😊
As the new lead maintainer of Actix Web (since September), it's sad to me that this video is still the first result when searching "actix" on UA-cam.
Version 3.0 of the framework was carefully planned by many contributors over many months and ensured that known UB was fixed and *all* remaining unsafe blocks were vetted.
This video is important for historical reasons but it is by no means the current state of the Actix project technically or organisationally.
This is good to hear. Thanks for the update Rob.
Thank you for replying here. I am just doing some hobby project in Rust, and Actix Web seems like a great match, but these stories are off-putting. Seeing the currently active devs still supporting the project this way is great motivation!
I love that smug little grin you are constantly trying to hide.
John Titor?! But this is supposed to be the Steins;Gate worldline !!
mitsuhiko (the guy working at sentry) created flask.
Standard internet drama, seen it many times before in various guises. Still enjoyed the video content though, thanks!
Well tbh i think that the only "healthy" way to maintain an open source project is to be like Torvalds aka to be a reasonable dick. Maintainer shouldn't give two flying fucks about emotions of the community, they can hate him, love him - doesn't matter. What matters are code, facts and provable evidence, if you can't even formulate a reason for as to why your code should be merged, and prove it to the maintainer then well tough luck go make a fork and maintain it yourself. Drama shoudn't be adressed at all, wanna cry a river? Yeah, sure, go do that with snowflakes over there, you can pat each other on the backs while at it. Maybe that will cause some of them to toughen up and make their own fork of it.
The only real reason why any controversy of any sort should ever affect the code is when maintainer went nuts and started adding malware to their code and even so, what i think community should do is not trying to pressure original maintainer to do something about, but create a fork of it.
Oh and that issue of "other projects rely on THIS REPO" is just gold. It perfectly summarizes what i think is wrong with current developers. No one is obliged with keeping THEIR repo up, so the risk of it going down is always there, therefore dependencies shoudn't be downloaded live from their respective repos in the first place. Yeah it's much more convinient than traditional way of downloading them yourself or through centralised means, but that's exactly the problem: it encourages dependencie hell. Another problem with this "issue" is that instead of forking the library/rewriting code for it to rely on a mirror repo/etc. he is crying to the maintainer to guilt him into fixing other peoples issue. This is wrong on too many levels to even attempt to break down here. Oh and that "respecting your code" is just a peanut on top of that dung pile, why should i care about other people thoughts on my code? They don't pay me, they don't know me, and i don't know them so why should i care? For all i know they are just a bunch of code monkeys that collectively decided that shit pile worth its weight in gold.
Drama is detrimental to any work being done, the best example of that is freeems project. It's the project that never really took off exactly because maintainer loved drama, for crying out loud he even tried to take the fully independant alternative project into that cesspool of meaningless drama by accusing him of stealong something from his project(even though the rusefi is structurely different from the freeems, like in every way imaginable, oh and ofcourse freems guy never bothered to provide evidence as it is common with drama queens)
He should just say "Pay me!"
IMHO I think a maintainer of project has his rights over the code he wrote irrespective of what open source community thinks / expects from him. Imagine the amount of work it goes to write something of this scale. I don’t agree with what the maintainer said in those comments but without the actual numbers / methodical proof of what the pr is about, I can understand how hard it can get to think in terms of people contributing or making those prs
Ben, will you do a video on react-router 6 ? O-O
most likely
@@bawad awesome man, you are the best
Since they're already using unsafe, wouldn't it be faster or at least the same performance if they implement the same thing in C? Using UnsafeCell is basically just a bloated version of using raw pointers in C
community should've just forked. What do they think FOSS is about? They think they can do better, then go do that? Why bully the guy? I don't know why he went along with it either. Sucks.
I dont like the mainteiner approach. Sure, you have to be braindead to do that but there is no point on using unsafe. Even if you call clone, it doesn’t mean that the memory gets duplicated, thats the magic of llvm and rustc
Not everyone is Linus Torvalds to be that aggressive and stay strong
That was a well balanced post-mortem, well done.
This doesn't apply to most open source projects, the reason why it's so hard being a maintainer of this particular project is that virtually no one is using it, hence no extra passive income. If it were something like React or Redux, the maintainers can run it like a business, selling books and tutorials and stuff. The lesson should be, don't spend so much time to maintain a project that only a few people are using.
@@zk4144 "one of the most famous rust web frameworks" is still small because "rust web frameworks" is a small field to begin with
nothing close to the "Iris (golang) framework scandal"
The maintainer was at fault, he used unsafe everywhere where it wasnt even needed leading to potential security holes and he was a engineer at Microsoft he should have known better and when people tried to fix it he told them to F off.
Agreed. Never treat bad your contributors, or you'll deeply regret it later on. That's what happened here.
Agreed. Never treat bad your contributors, or you'll deeply regret it later on. That's what happened here.
I get being overworked and not having enough capacity to dive into the details of pull requests. Despite that I think the maintainer handled the situation terribly.
Memory safety is the defining feature of rust. It is a widely accepted best practice to make sure that no undefined behavior can occur.
A project that deviates from this widely adopted practice should make sure to communicate that, something for a CONTRIBUTING.md which rust doesn't have.
Moreover, if you don't have the capacity to thoroughly review a pull request, say so right away.
Just having 2 outstanding mutable refs to the same object is UB? _That's_ the reason why unsafe is not for everyone: not everyone even understands what actually triggers UB!
For the Rust compiler, this is UB, and once you have two mut references, the compiler can do whatever it wants with your code. In other compilers, it might not be, but Rust assumes that this doesn’t happen, and optimizes based on it.
@@Ninjacatburger Especially if you are using standard library types, which in all fairness to the PR author, the creator was.
Bruh, Mitsuhiko is the creator of Flask for Python :joy:
Wasn´t branching an option?
Over a single unsafe block? Ugh...this is why Linux will never win on the desktop.
That is the whole the reason to chose Rust over other compiled languages in the first place: when you need safety over everything else, no matter what. Otherwise why would you chose it? Because it is trendy? Because your fried told you it is cool? That is not a reason enough, even if you write software for fun.
There's two kinds of safety violations, "I shot myself in the foot" and "it's someone else's problem". You don't fret over every library in C either do you, you generally assume that curl or something is reasonably written and tested and does what it says on the tin. It's someone else's problem.
If you don't want to shoot yourself in the foot, Rust is a reasonable choice. But to achieve less friction and better integration, less overhead, less effort, you can be inclined to use Rust native libraries. How they remain safe, whether by language features or by other means is "someone else's problem".