'I am done with open source': Developer of Rust Actix web framework quits, appoints new maintainer

The maintainer of the Actix web framework, written in Rust, has quit the project after complaining of a toxic web community - although over 100 Actix users have since signed a letter of support for him. Actix Web was developed by Nikolay Kim, who is also a senior software engineer at Microsoft, though the Actix project is not …

[Charlie Clark]

Not just open source

Be[ing] a maintainer of large open source project is not a fun task. You['re] alway[s] face[d] with rude[ness] and hate, everyone knows better how to build software…

This could apply to any software project. The key is always communicating clearly and setting reasonable expectations. If your project is successful and popular you will attract the slugs, the uses who want it to do everything for them but aren't prepared to contribute. Be prepared to write "design defence" documentation to defend your decisions and be firm but fair. At the end of the day, you decide what gets accepted and what gets rejected. Some people will never accept this: get over it, because there are fuckwits all over the place, but don't get dragged into their discussions. As I think Mark Twain said: don't argue with an idiot, they'll drag you down to their level and win.

But, one of the great things about open source, be prepared to walk away and let someone else take over. Software development and review takes time and energy which we don't always have as much as we'd like. Our lives and priorities change.

[Anonymous Custard]

Re: Not just open source

The full quote is:

“Never argue with an idiot. They will drag you down to their level and beat you with experience.”

But aside from that, very much thumbs-up agree (speaking as a board director of a major FOSS project myself).

[James 47]

Re: Not just open source

Are you serious?

People publish Open Source software because they're hobbyists who think others might find their work useful. They owe anyone else absolutely nothing! Others are totally free to not use their software.

Who in their right mind would spend a weekend writing a 'design defence' document? Crazy.

[Anonymous Coward]

Re: Not just open source

> Who in their right mind would spend a weekend writing a 'design defence' document? Crazy.

Someone who values contributors, and wants to share their expertise about the project to improve the quality of contributions?

[Oh Homer]

Re: Apathetic hobbyist or community contributer

Actually you're both right, depending on the motive.

It's certainly legitimate for someone to apathetically dump the end result of their personal itch-scratching exercise into the public domain, in a half-baked act of philanthropy. I'm sure that is how at least some open source projects begin life. In such cases, expecting the original author to spend days carefully crafting policy documents is not very realistic.

However, it's far more common for open source to begin for more pragmatic reasons, where the license is chosen specifically to encourage community contributions, to distribute the workload among many, in terms of both developer contributions and public scrutiny. In such cases, the community surrounding that project is certainly no peanut gallery, and you absolutely need to listen to what they're telling you, assuming you wish to continue receiving their contributions, that is.

In this case, it seems that Kim started out as one of the latter, then ended up as one of the former.

It happens. Many open source projects see a lot of leadership changes due to irresolvable conflicts of interests, where tempers fray and people storm out. Exactly the same thing happens with proprietary software development too, of course, except behind closed doors, so we rarely get to hear the details.

Whether or not there's any benefit to seeing developers air their dirty laundry in public is debatable, but it's certainly entertaining.

[M. Poolman]

People publish Open Source software because they're hobbyists

I was trying to think of a sensible reply to that, but remembering the quote from AC immediately before yours, it would probably be a waste of time.

[Charlie Clark]

Re: Not just open source

People publish Open Source software because they're hobbyists who think others might find their work useful.

I am serious and I do run a reasonably popular open source project. Communicating clearly why your library works they way it does means you don't have to continually explain and justify it.

Not taking any shit from your users does not mean you have to treat them like shit. See the Mark Twain comment as to why this is important. The vast majority of users will be happy with what you have but some may well take the time to make worthwhile suggestions or submit patches / pull requests. The trolls are best just ignored (or banned).

[bombastic bob]

Re: Not just open source

"People publish Open Source software because they're hobbyists who think others might find their work useful."

Although I am certain that there are many people who fall into this particular category, you are being QUITE arrogant if you make the assumption that ONLY "hobbyists" publish open source.

I had someone say "hobby" with respect to a serious hardware project I had designed for my own company. I considered that to be BOTH condescending AND arrogant. Well, *THAT* guy's contract ended early, for a number of reasons, in a major project we were both involved in. He was one of those "UX" designers who "worked" by slapping canned packages together, writing sloppy code that barely worked, and calling it "a user interface". Oh, wait, that's "User eXperience". *facepalm* (he couldn't meet design deadilnes, even acted out and deliberately interfered with getting things done - last I heard, he applied to work for the EPA, suits him perfectly I guess)

yeah, _I_ took over his duties, and actually made the thing work, cursing his name and choices for MONTHS... [customers happy with it though]

[Anonymous Coward]

Re: Not just open source

Hmm, the super hero pattern.

We have someone like you on the project I'm on atm. Could help us deliver but prefers to let us deliver wrong so they can point out how much better they are than us.

Not particularly useful but no doubt they have a history of "successful" projects like you do.....

I like to work on a team.

[BigSLitleP]

Re: Not just open source

It doesn't sound like you like to work on a team. It sounds like you like to moan about other people and not look at yourself.

[jelabarre59]

Re: Not just open source

It doesn't sound like you like to work on a team. It sounds like you like to moan about other people and not look at yourself.

So if someone's toxic attitude is dragging the rest of the team, you're not allowed to point that out? How very woke of you.

[unimaginative]

Re: Not just open source

Can we please finish the "open source is written by hobbyists" myth?

Yes, hobbyists CAN contribute and some do. However most open source contributions are made by professionals in the course of their work, and even most of the volunteer contributors are professionals either helping something they want to support or publishing code to help them find work (the two are not mutually exclusive, of course).

Outside some Linux desktop stuff (mostly KDE) I find it hard to think of any open source stuff I use (and almost everything I use is open source) that is primarily developed by hobbyists.

[jake]

Re: Not just open source

I think you'll find that virtually all of the core *nix utilities were/are developed by hobbyists and/or students. Likewise most of the core Internet software. To say nothing of GCC and the rest of the toolchain. Etc, etc., etc.

Your so-called "professionally built" system wouldn't even boot without the time and effort put in by thousands of hobbyists over the last 50+ years.

[Doctor Syntax]

Re: Not just open source

Be prepared to write "design defence" documentation to defend your decisions

Or perhaps start out by having at least an initial plan, what's in scope, what you envisage the structure to be, the rationale behind this and document that. The document can evolve. Anyone who wants to change scope etc gets invited to explain how and why they think this could/should happen.

[JohnFen]

Re: Not just open source

> This could apply to any software project.

I suppose it could, but I've been in this industry for 30 years or so, and I've rarely encountered this sort of problem outside of the OSS community, and even there, it's only become a real issue over the last 10 years or so.

[jake]

Re: Not just open source

And it's only become a problem because a few entitled induhviduals have been fed a bill of goods and think that "every child is a winner" so all their contributions simply MUST be valid. Mummy said so!

During the meanwhile, in this particular case the adults in the audience are yawning. Or pointing & giggling, depending on how many glasses of Recovery they've managed.

[doublelayer]

Re: Not just open source

Well, your experience is not like mine. I've seen exactly this in many closed source projects. People want the project to do what it does with a completely different interface. They're willing to commit a readme that lays out that interface if I could just fill in the gaps. Or they'd like their project and my project to merge because our functionality compliments one another. They'd be happy to modify the code to do that as long as I deal with all the bugs because they haven't read the code to my project before making the suggestion. Some times, these people are making constructive suggestions and my team should consider what they're asking for. Sometimes, they are very skilled and dedicated and they'll be valuable assets to our team; at least one person I respect quite a bit joined us in that very manner. Sometimes they have no clue what they're talking about and should be ignored, and if we didn't figure out this we'll be cleaning up after the disaster for quite a while.

[Dan 55]

Re: Not just open source

When project deadlines are squeezed in the constant race to the bottom, documentation quality is usually the first to go, just enough to tick boxes to say it's been done. Then later on everyone's utterly surprised when nobody knows how anything works as the original people are unavailable (they're busy having the same problem with other projects or have been fired).

[Notas Badoff]

Re: Not just open source

"The key is always communicating clearly and setting reasonable expectations."

Amazed that no one has mentioned Python and Guido van Rossum. Even when you do everything right, the wrongheadedness wears you down. After one more fraught PEP which should not have been so bone wearying painful, Guido took off the BFDL hat. After 28+ years of doing right by people.

[bombastic bob]

Re: Not just open source

"If your project is successful and popular you will attract the slugs, the uses who want it to do everything for them but aren't prepared to contribute."

well said!

Also a corollary of that: don't try to make your project do TOO much or it will bloat into an uncontrollable mass of feature creep. If the 85/15 rule applies, let's say 15% of the effort going into 85% of the functionality, and the rest of the functionality (15%) taking up 85% of the time and/or amount of code to support it.

Contrast this to the UNIX principle of "do one thing, well".

So at some point, all of that extra functionality should become add-ons and not built-ins. Then when the slugs complain about "no feature" you can say "write a plugin, contribute it, and then it will do what you want". So simple!

then again, if you do like Firefox and CHANGE THE API such that the old plugins break...

[DrXym]

it's a very nice library

I've used it to write an http / websocket server and I found it very easy to get going. Actix frequently tops web server benchmarks so it's very scalable too.

[I Am Spartacus]

Re: it's a very nice library

That is indeed true.

It is also true that writing RIST code is not easy. It is very hard indeed, and requires taking a step back from what we normally consider the way to do things in languages like C, C++, C# or Fortran. In RUST memory has to be treated with respect. By comparison, if you treat memory with respect and code to RUST's exacting standards, the compiler will created and guarantee memory and thread safe code for you.

But if you start saying that this is just too hard, or too slow, and that you know best, you can quite easily create UNSAFE code that basically tells the compiler you know best. Sometimes you have to do this, for example when interfacing to raw block structured devices. You have to map the memory array in to a RUST structure and yes, you do know best.

But if you do this in application code, you are building a product that breaks the contract. Users will take your library and rely on it, because, well, it's written in RUST, so if it compiles, it will be 'safe' (for what the RUST compiler thinks is safe). But if it turns out that its not thread safe, or it doesn't play nicely with dandling pointers, etc. you are leading the users up the garden path.

So, a better approach would have been for those people who wanted a RUST safe version of Actix to fork the project, correct what they perceive as coding errors , and benefit the whole community.

[bazza]

Re: it's a very nice library

To be fair, memory has to be treated with respect in all languages. Rust in safe mode simply doesn’t give you the choice. I’ve often thought that “safe and unbuggerable” code in languages such as C, C++, even C# depends heavily on people assuming that “no one would ever do that, would they?”!

It does indeed seem slightly odd to be using Rust in an unsafe way for something that many would indeed assume was inherently “safe”. Caveat Emptor and all that, but my first reaction to the headline was “oh goodie, something good written in Rust!”, dashed to some extent by the details :(

[DrXym]

Re: it's a very nice library

The thing I like about Rust is it's safe by default and if you do need to do potentially dodgy stuff then you must enclose it in an unsafe block. You can simply search and find it with ease. I realise actix has gotten flak for some unsafe blocks but I see the fact that people could even see and review them as a feature not a bug.

[bazza]

Re: it's a very nice library

That is a way of looking at Rust that I’d not even considered before, but I agree wholeheartedly. If I may say so, that’s an excellent observation on the situation.

[DrXym]

Re: it's a very nice library

Writing safe code in any compiled language is not easy. Rust just prefers you find out when you try to compile it rather than down the road when customers do.

[werdsmith]

Re: it's a very nice library

To be fair, memory has to be treated with respect in all languages..

Memory should be treated with respect in all languages.

[cschneid]

PL and TL

> The episode demonstrates that expert developers are often not expert in managing the human relations aspect of projects that can become significant.

Prior to leaving the codeface for a seat by the fire, the last place I worked was developing the concept of a Project Lead and a Technical Lead who would work in tandem. The former would arrange meetings, record notes, was the keeper of the project schedule, communicated with the user community and with management, and handled the myriad of complexities that surround a project. The latter was the architect, designer, editor-in-chief for the myriad of complexities that are the project.

[baud]

Re: PL and TL

> a Project Lead and a Technical Lead

It's close to the current organisation in my team: our manager is doing the Project Lead, with very little technical work, since her technical skills are not applicable for the current project. But the role of Technical lead is distributed among the developers, each having their area of expertise, plus a part-time architect.

[James 47]

Re: PL and TL

An Open Source project doesn't need a management hierarchy. That's the point, it's a place for developers to do what they want, how they want, without having to answer to anybody. If no-one uses it that's fine.

[Charlie Clark]

Re: PL and TL

Any project needs a way of taking decisions: this doesn't need to be a hierarchy but the concept of "benevolent dictator" is common for this very reason.

[Doctor Syntax]

Re: PL and TL

AKA Maintainer.

[imanidiot]

Re: PL and TL

That depends very much on the size of the project and the type of contributors. Something the size of the Linux core or Actix is very much in need of someone keeping things in line, because some people WILL bugger things up with the best of intentions if left to their own devices.

[Anonymous Coward]

Re: PL and TL

We used to work like that, until the beancounters decided that what the Project Lead did was essentially low-skilled overhead which could easily be handled by the Technical Leads, so they laid off the Project Leads. You can guess what's happening to product quality.

[A.P. Veening]

Re: PL and TL

Such a shame the beancounters never understand they are useless overhead themselves.

[quxinot]

Re: PL and TL

It's difficult to get most beancounters to understand their optimal role, and even more difficult to get them to do it.

You see, it takes time for compost to release the nutrients to the soil. Particularly if it's through a thick carpet....

That said, their intermediary use of high dielectric insulation for cattleprod calibration they generally understand fairly rapidly.

[Tomato42]

Re: PL and TL

ya see, you should have used wool carpet, not synthetic one!

[quxinot]

Re: PL and TL

Can't get wool carpets approved because the beancounters nix.....

Huh.

Hrm....

[Anonymous Coward]

Yeah...

Giving low-skilled overhead to those technical leads sounds like overspending to me. Sounds like your accountants are idiots which think there are an infinite number of hours in the day.

My employer hires low-skilled employees for the project lead jobs, saves them significantly in $/hour.

[David Austin]

Re: PL and TL

It's a good idea: each job has it's own skillset, and finding a person that can fill both competently massively narrows the application pool (And with your manager hat on if you're in that position, may not be cost effective, as the savings of one larger salary over two is trumped by the body count going up).

[Anonymous Coward]

Re: PL and TL.. reinventing the wheel..

Back in the good old days when we used to ship shrinkwrap software on physical media, 3 1/2 floppy disks, we used to have this guy in the dev team called the Project Manager. They did exactly what you outlined. You had the Tech Lead / Architect (usually me) with a bunch of Senior and Junior programmers. Then we had the Project Manager who took care of all the organizations stuff for the dev project apart from direct code related stuff.. Such as dealing with the UI and Art Assets depts. And getting the final product physically produced. Then we had a Product Manager who took take of the business end. Marketing / sales / docs / support stuff. Then we had a QA Lead who took care of getting our product through QA. We always had a docs person who came on board near the end. Remember documentation. Not just a bunch of badly structured web pages but a proper manual. Written by people who could actually write clear lucid technical prose.

I have nt seen a real product dev group like than for quite a few years now. I have seen a whole bunch of dev teams who claim to be "Agile". Which in my experience means none of us know how to design or architect non-trivial code and none of us know how to manage a dev team. And none of us know how to ship code that is stable and feature complete.

Which is why your installed applications now try to continuously update. Because none of the dev teams know how to write stable clean code hence all the regular bug fixes. Of trying to complete feature that were only partially implemented before being released.

[Anonymous Coward]

Re: PL and TL.. reinventing the wheel..

You sound like you work for the NHS....

[Anonymous Coward]

Re: PL and TL.. reinventing the wheel..

Nope. Not NHS. Just pretty much ever successful US PC software company back in the 1980's and 1990's. I saw inside pretty much all of them on the West Coast at some stage or another.

Once annual revenue went above $10M or so that's how they organized product development. Actually having to produce physical product and the cost of the initial dup run being several $100'ks just to get product into the distribution channels imposed a lot of discipline on the process. Cost of fixing a crash on startup on certain hardware configs after product went to Golden Master and you had to do a recall ran to a largish six figure sum. And unlike dot coms, these companies were actually trying to make a profitable business out of selling product to end users. Not just some financial engineering scam.

[Anonymous Coward]

Re: PL and TL.. reinventing the wheel..

Most hardware / manufacturing companies that I've worked at in the UK are still run like that - when you have to commit to £200k+ tooling which can't be changed after it has been hardened it concentrates the mind wonderfully!

[Mike Moyle]

"...and that its community gets a better handle on how to proceed constructively."

It would be lovely to think so, but (to paraphrase Westley of Florin) "No good... I've known too many engineers."

[bombastic bob]

Re: "...and that its community gets a better handle on how to proceed constructively."

"Inconceivable!"

(good reference by the way)

[LosD]

- Deleting valid issue reports

- Threatening to delete the project

- Claiming that no-one can take over

- General bitching about others

Yeah, totally sounds like it is everyone else that is the problem here.

[detuur]

Let's not forget that the commotion only really started when a helpful lad—at the maintainer's request, mind you—wrote a patch fixing a race condition and his only response was "this code is boring".

[andy 103]

People skills

I'm going to try and post this without giving too much away but around 10 years ago I worked with someone who developed an ecommerce platform. This was when Magento was still fully open source (before Adobe purchased it) and essentially his system was a rival to it.

I remember reading his rants online at people who were criticising his work and essentially telling him it was shit compared to Magento (which is saying something because at that time Magento really was quite shit).

For me it was a very double-edged sword. He had put considerable amount of time and effort into doing something he loved. Nobody really thanked him for it. The platform still exists and has done reasonably well, and kept open source. Some online retailers use it and make decent turnover through it. Meanwhile Magento was purchased by Adobe for £shit-loads and isn't open source**. But on the other hand, his responses and inability to take criticism were, in my opinion, a massive failure in terms of why he didn't succeeed as well as he might have done otherwise.

In summary I both feel sorry, yet have little sympathy, for people in this situation. It's hard to know where the line is.

They're doing something positive but their lack of people skills (Linus being a classic example of someone who many people consider an arsehole even though he's done plenty of "good") is the real problem.

** Well there is an open source version but nobody really cares about it. The one people are using isn't open source.

[Anonymous Coward]

Re: People skills

Magento (even Enterprise) is still quite shit. We run several multi-million dollar e-commerce sites on it.

AC because we had to sign a non-disparagement agreement to be able to license it. That says a lot about a product doesn't it?

[tcmonkey]

Re: People skills

Sure does. I worked with both Magento 1 and 2 a few years ago and I can safely say that I would rather dig graves for a living than go back to it. At least they'd be for other people rather than for my own sanity, which was being steadfastly murdered the entire time.

[JohnFen]

He's not wrong

Large swaths of the open source community have become intolerable. It's why I stopped actively participating in the OSS community a few years back -- it's just not worth the trouble.

I release most of my software into the public domain these days, but I do still release some software under OSS licenses. However, none of them are community-driven. I offer them on a take-it-or-leave-it basis.

[Charlie Clark]

Re: He's not wrong

I don't think there ever was an an "OSS Community" that wasn't project specific.

[JohnFen]

Re: He's not wrong

There used to be. Perhaps there isn't anymore. In any case, this behavior has become very common across projects -- so much so that it's why I've essentially left the wider OSS community (if such a thing exists) and no longer participate in OSS projects that aren't mine.

[jake]

Re: He's not wrong

"There used to be."

Disagree. Individual projects, yes. But an over-all OSS community? Nope. That only existed in the deluded dreams of rms and a few like-minded idealists.

[bombastic bob]

Re: He's not wrong

yeah this "community" thing usually gets conceived as something *really* *nauseating*, all "touchy feely" and "we all just get along", which is the EXACT opposite of STARK REALITY.

A "community" (read: small group) of contributors who submit patches and occasional features is fine, but SOMEONE has to have the gonads to say YES or NO to all of that. Because, we do NOT all "just get along". There are agendas and personal vendettas and crusades and "i want this feature dammit" and so on... and *WAY* too much *FEEL*.

maybe this is why what the CUSTOMERS (i.e. end-users) want has become such a LOW priority these days... you know, like with major ball-busting changes like Australis, Gnome 3's UI, 2D FLATSO, removal of user customization, EVERYTHING looks like Chrome and CHROME LOOKS LIKE CRAP (all bright blue on blinding white), et cetera, et cetera, et cetera...

[tekHedd]

Re: He's not wrong

I stopped giving away software some time ago. Paying end users are generally much easier to deal with. Or maybe it's something about the "they gave me money" part that makes it easy to forgive their little quirks.

[Charlie Clark]

Re: He's not wrong

There's something in the aphorism that if something costs nothing, it has no value. Open source isn't about being free at the point of use, though this is often the case.

[Roland6]

Re: He's not wrong

>"if something costs nothing, it has no value.

Open source isn't about being free at the point of use..."

That is a good point.

Years back (pre-www) you had to pay someone real money (ie. more than the cost of the media + p&p) to get your hands on a CD of open source code which you were expected to compile.

Now it seems everyone thinks that a ready-to-run distro is open source and should therefore be free, likewise the automatic updates.

Yes, I know about the marketing considerations and technology advances that have influenced the decision, but it is clear we have become accustomed to an unsustainable state-of-affairs. It would be interesting to see what the market reaction would be to an open source product (distro or application) that came with usage limitations (eg. 30 days limited trial, updates disabled etc.) that could be unlocked for a subscription... Wouldn't be surprised if MS are or have seriously looking at this possibility.

[jake]

Re: He's not wrong

"Years back (pre-www) you had to pay someone real money (ie. more than the cost of the media + p&p) to get your hands on a CD of open source code which you were expected to compile."

Your version of history doesn't match mine.

We sent out early 1BSD tapes (1978), at no cost, to anybody who asked. Granted, not many people asked ... but there was no money exchanged. This got spendy, especially on a grad student's budget, so with 2BSD (?? late 1BSD? My mind is concatinating time again ...) we required them to send us the media and a postage paid return envelope. Soon after this, it was available via anonymous FTP from all the usual places. Again, no money exchanged hands.

IBM, DEC, et alia freely shipped the system source along with the hardware as a matter of course until the likes of Steve Jobs and Bill Gates discovered that leasing/renting software was more lucrative than including it with the hardware.

[Roland6]

Re: He's not wrong

Your knowledge of Unix history predates mine :)

When I encountered Unix (mid-1980's), the tapes were no longer being sent out for free.

Thus I was referring to the period - circa mid-80's to mid-90's - when CD's were the distribution media of choice for various 386/PC Unix distributions and then Linux, and companies such as Walnut Creek were burning CD's of Unix/Minix source code and Linux distro's such as Yggdrasil. I seem to remember they charged a "rip-off" price of £5~10 per CD(circa £15 to £30 in today's money).

Yes, if you could afford a network connection (pre-Unipalm/Pipex days in the UK) then I agree anonymous FTP was the way to go. Mind you back in 1988, we regularly downloaded updated versions of Sun's complete OSI stack (including FTAM and X.400/MHS) as an SMTP attachment over whatever passed as 'fast' (for normal people) in those days.

[jake]

Re: He's not wrong

Yes, there was quite the little industry building & selling CD "collections" of freely available porn source and binaries. I sometimes forget about that, though ... I had access to the early Internet before it was TCP/IP, and had a server under Bryant Avenue in Palo Alto connected to Stanford via 56K (officially for access to the DECUS archives), and later in the mid-80s T1 into BARRNet and the NSFNet beyond.

archive.org has a bunch of the Walnut Creek & etc. ISOs available online.

[FuzzyWuzzys]

Re: He's not wrong

"I stopped giving away software some time ago."

Funny you say this, I used to give my photos away to artists and anyone who asked but it was too much trouble. Initially it was hard to stop doing that and start charging money for them but since I decided to stop giving stuff away and charge people it's been much easier and less stressful. The more you give away the more people seem to want from you and whatever you give is never enough and they want more, they think just 'cos you give something away for free they have a every right to criticise you and the product, whatever it is. Paying customers don't pay until they're sure and 'cos they only pay out when they're sure they almost never complain afterwards.

I hate thinking like this and it goes against my better nature but sadly human nature has taught me that a lot of the time it's simply not worth giving anything away for free that you've created, people rarely appreciate it and a lot of people just want more.

[bombastic bob]

Re: He's not wrong

"Large swaths of the open source community have become intolerable"

This is why you need a project manager with a heavy hand that isn't afraid to say "no", or even "NO!" or "*HELL NO*!!!", as well as enforcing coding style consistency, and putting certain kinds of pull requests permanently on the shelf.

Someone like Linus, let's say. .. WITH the profanity and unafraid to insult people. [I particularly like his comments regarding 'compiler masturbation' by which he meant using "new, shiny" features simply because they were there, not because they were better or easier to maintain - which in the cases he pointed out, were NOT]

[karlkarl]

Fair enough,

Open-source often means very large user-bases. Large user-bases aren't for everyone.

Its often a bit awkward, but sometimes an open-source project can outgrow its original developer. Especially if they are a little bit old fashioned. It happened to me but frankly I am very glad the community took it over rather than the whole thing die.

[HammerOn1024]

Owee

Boo hoo... baby got an owweee. Look. The nastiness everyone could do without. But PURPOSELY deleting bugs? Yeah, that would get my boot up side your backside.

Ignoring peoples issues? Simply having a list of bugs to be fixed and their order would address that.

Simple stuff here, so it's probably a good idea for someone with thicker skin to take on the job.

[J27]

Re: Owee

What job? He was a volunteer. Entitled whiners screaming all night would make anyone quit their volunteer position.

[Anonymous Coward]

Whats the problem with unsafe code in Rust?

"Rust is safe by default, but the language also supports unsafe code, which can be useful for interoperability or to improve performance."

If Rust is supposed to be a systems programming language and a replacement for C/C++ then unsafe code is a must since you can't talk to I/O ports or device memory directly if everything is in a sandbox. The reason for unsafe code isn't really the ones given abou, its because if Rust is to live up to its design ideals (it won't IMO, C/C++ has way too much traction) then it has no choice and any Rust developers bitching about it clearly don't understand what systems programming is all about and are probably just Kool Kid Webdevs trying out the latest fad language.

[diodesign]

Re: Whats the problem with unsafe code in Rust?

FWIW you still have to obey Rust's borrower rules in unsafe code. You also wrap unsafe { } around unsafe code so you can find and audit it easier - whereas with C/C++ any old pointer could be wild.

Unsafe IO port access on Rust looks like this:

unsafe { *(0x10000000 as *mut u8) = c };

..for writing a character to a serial port at 0x10000000, say.

I've done a fair amount of low-level Rust dev in my spare time and it's helped me write much better code, so much so, I am terrified about the thousands of lines of C I've previously written.

I'm not on the Kool Aid, though. It's frustrating that a lot of the ecosystem uses the standard (std) library, which is unavailable on bare metal. Thus, you may find a third-party library that will save you reinventing the wheel, only to find it's reliant on std and you can't use it.

C.

[patrickjp93]

Re: Whats the problem with unsafe code in Rust?

The Rust standard library isn't available on bare metal? Huh? Even the C std library is. Yes, you usually have to tell the compiler to bundle it into your executable directly (take a copy of the needed parts), but Rust doesn't have this capability yet? If not, smack the compiler maintainers. This is not particularly difficult to do with an "--embedded" or "--baremetal" flag honestly. You can implement the threading constructs in your executable if you're using parallel algorithms and thread-safe concurrent data structures.

[diodesign]

"The Rust standard library isn't available on bare metal?"

For bare metal, you can use what's called the core library, and a few others, that provide primitives and basic structures. There's no IO nor heap allocator: you have to implement that yourself.

If you pull in a third-party library that expects to use std library primitives, you're out of luck in a core-only environment. It's not the end of the world: not all libraries require std. Ones labeled nostd will work with core.

std expects there to be an OS underneath providing stuff like heap allocation and IO. With bare metal, there is no OS. You are the OS. Core doesn't require an OS. Core expects you to provide things like the heap allocator.

So, with core, you're not totally on your own, you get some support, you just can't use dependencies that require std, and you have to provide stuff like memory management.

Compare std: https://doc.rust-lang.org/std/

to core: https://doc.rust-lang.org/core/

Core gives you a lot, along with common data structures in the alloc library, but not all of std.

C.

[bombastic bob]

Re: Whats the problem with unsafe code in Rust?

"whereas with C/C++ any old pointer could be wild."

Not when you write the code properly. An experienced kernel programmer would know this.

(if you're talking new college grads first time trying their hand at coding, that's completely different, but when you've been coding longer than those people have been ALIVE... *NO* need to limit things or over-generalize the 'paranoid case' just because SOME people just aren't competent enough)

[thosrtanner]

Re: Whats the problem with unsafe code in Rust?

Yeah. And all code is written properly of course. Even experienced kernel programmers make mistakes.

Something I learnt long ago: Given 2 code solutions to a problem, people in general pick the worse one either to use or to (shudder) clone and mangle.

[RyokuMas]

Re: Whats the problem with unsafe code in Rust?

"And all code is written properly of course."

Oh, but real programmers write bullet-proof code - didn't you know this?

And, heaven forbid that we let college grads write code that actually goes into production, just in case they develop this "experience" thing, come up with new ways of solving problems and put all the ageing code hacks who are too stuck in their ways to accept change out of a job...

[Roland6]

Re: Whats the problem with unsafe code in Rust?

But what is "safe code"?

Thread safety has been mentioned, however, unless I've missed something over the decades, writing code that is safe with respect to re-entrancy and accessing the same data structures/memory and other fun and games of parallel and multi-threaded execution, still requires the programmer to have the ability to write "safe code".

Another aspect, is that "safe code" is really only with respect to the module being compiled, You have to trust all other code executing within the runtime environment is also safe. I wonder if this is part of the complaint being made about RUST, namely, it doesn't go far enough in supporting runtime trust, ie. I should be able to set an OS parameter, so that anything running in 'user space' or outside of the OS rings has to be flagged as "safe code".

[Anonymous Coward]

Re: Whats the problem with unsafe code in Rust?

>C/C++ has way too much traction

'C' os an example of what used to be called a Systems Programming Language. Its essentially an overgrown macro assember. Systems languges were intended for operating system and tools writers, not applications developers, they only found their way into applications because of the shortage of better tools during the early PC years. These languages don't need support libraries although most people will see them with a couple of entities that make them useful for scratch program writing, these being the crt0 environment setup for the initial call and some kind of input/output package and processor instruction replacement package for data types the processor doesn't support directly. Because of the level of control they give you over the environment they're really easy to abuse -- its why they're regarded as 'unsafe' (but then you've got to write the safety mechansms in something!).

'C' got into the applications business because there wasn't a lot of other compiler support for early PCs. It wasn't suitable for the job -- writing GUI applications in 'C' is a nightmare -- but unfortuantely the extension that gave improved scoping and structure support (C++) turned out to be particularly suited to the needs of GUI programming. Since a GUI became the first and most common environment people were exposed to it became de-facto way of writing all software. Ironically event-driven programming (GUI) technique was originally a kludge to give the effect of having an operating system on a system too small to actually host one. It worked but to do anything more than support a stack of windows and one or two simple timers required all sorts of new kludges and workarounds. And so modern software was born......

[bombastic bob]

Re: Whats the problem with unsafe code in Rust?

I think you overgeneralize too much negativity about the C language [which I use ALL of the time]

And YES, I've done GUI programs in C.

[Roland6]

Re: Whats the problem with unsafe code in Rust?

Whilst I agree AC was overgeneralising, the main thrust of their point is correct; C is a powerful macro assembly language.

Back in the mid-80's Unix became massively popular, especially with Universities so many graduates had Unix and C skills. Fortran, Cobol etc. were seen as 'dated''. Add into this mix the desire/need to develop serious programmes for the new microcomputer/PC platforms ie. requiring something other than Basic or Pascal. Hence why the company I worked with ported their programmer's workbench from Unix to the PC; becoming the first C language development environment on the PC for the PC.

However, all of these were difficult for the new generation of largely self-taught programmers, hence why we had Turbo-Pascal, VBasic, Delphi etc.

[jake]

Re: Whats the problem with unsafe code in Rust?

"becoming the first C language development environment on the PC"

You worked for Mark Williams Company in Chicago?

[Roland6]

Re: Whats the problem with unsafe code in Rust?

>You worked for Mark Williams Company in Chicago?

No, although I did come across Coherent. Being a bit sloppy, forgetting the attempts to get people to run things other than MS-DOS on their PC's... :)

The product I was referring to was reviewed by Dick Pountain in Byte magazine Vol.10 Issue 12 p419

It was also reviewed in the Jan'86 edition of PCW, but the PCW archive doesn't go that far back.

[jake]

Re: Whats the problem with unsafe code in Rust?

I wasn't talking about Coherent, I was talking about Mark Williams C ... most people know about the version that ran on the Atari ST, but they did an MS-DOS version, too. It was one of my go-to tools ... The thing was fully K&R compatible, and was fast, small and tight, being entirely hand coded in assembler. You could develop and compile tools for UNIX and the Atari-ST using the DOS version.

You could fit (and use!) the whole system, including compiler, assembler, linker, libraries, source debugger, decent screen editor (MS-DOS version of MicroEMACS hacked into an early version of an IDE), crude source code control, etc. on a single, DOS-bootable 1.44 Meg floppy. Here's a link to it's little brother "Let's C", with some blurb.

I remember reading that article in Byte, and in fact I bought a copy of Living C-Personal based on it. Still have it, in fact. I honestly don't remember ever using it in anger, though ... MWC did the job for me when I needed down & dirty C on DOS ... otherwise I was hacking BSD with pcc, as Gawd/ess intended :-)

[Roland6]

Re: Whats the problem with unsafe code in Rust?

Sorry now you have spelt it out, I do remember Mark Williams C, but didn't get a copy and so use it.

I forget which compiler was ultimately used for the released version of Living-C as at various times we used: Aztec C, Lattice C, Digital Research C and then MS C 3.0.

One of the discussions (the conclusion to which was superseded by events) was whether we should build our own assembler, linker, libraries etc. or provide the means for Living C to drive third-party tools...

Personally, Living C-Personal, was (and still is) a really great tool in which to learn the C language and test the logic of a module (we used it to build Living C), because you were working consistently at the C language level. The only other tool that I'm aware of which had the same level of user working was Micro Focus's Animator for Cobol (which predates Living C...).

[bombastic bob]

Re: Whats the problem with unsafe code in Rust?

there are many reasons I do not use the Rust language, low-level code efficiency being one of the big ones.

I don't much like their model for threading either. I'd must rather hand-tweek my own algorithms based on the understanding of the system they run on, Then you can decide whether the overhead of a job queue is worth the performance benefits of spawning multiple threads, from the total number of simultaneous jobs you can run [based on the total # of CPU cores available], to the nature of the threads themselves (do they have I/O wait states or in any way lock global objects or cause priority inversion) and so forth.

And when you've been coding long enough, you can use pointers SAFELY. It becomes SAFE CODE because you WROTE IT to BE SAFE.

There's really no substitute for proper design and techniques, ESPECIALLY _NOT_ some "new, shiny" language that pretends there IS...

my language of preference: C, or C++ when the need arises. It usually doesn't. And good C++ code looks very much like good C code.

[Elledan]

It's all relative

A lot is made about Rust being 'automatically safe'. This is a massive lie. Maybe it does offer the same kind of memory safety that modern C++ offers, but it will not protect you against corrupting data by an unintended write/truncate or logic errors. The compiler has no clue what the code should be doing, after all.

This is where the Steelman requirements that underlie for example the Ada programming language offer a lot of insight in what makes a good language. Preventing logic errors and kin is done through reducing the complexity of the language (fewer ways one can write similar code), by making the code easy to read and understand (Ada doesn't use a lot of abstract symbols, but prefers plain English) and requiring explicit types, not allowing for any kind of inference, as Rust happily does. Oh, and contract-based programming is really useful, as offered by Ada/SPARK and Ada 2012.

Toss this current drama on the pile with the other 'Rust is used by people who do not understand programming languages' items, I guess.

[DuncanLarge]

Oh dear

Sounds like a case of:

"I wrote the code, stop asking me to do it properly".

In this day and age, when given a language like Rust that actually works hard to make code safer, you'd think that a developer of a web framework would work hard to ensure the safety of this code.

Ditch the performance and interoperability. Thats a problem for others to sort, such as fixing their browsers to work in a more interoperable way and do we really worry about performance now? We are spoilt with huge amounts of memory and processors with 64 cores. I remember the "breaking of the 1GHz barrier" being a big thing, on a single core machine which MIGHT have 1GB of RAM.

Security is everything when concerning the web these days and if this developer was acting in this caviler way regarding using the features of Rust to provide what should have been a good attempt of bringing a secure development platform to the web then I say bye bye and good luck to him. Your users were demanding something that basically was common sense these days, you had a chance to create a platform that developers would flock to knowing that its secure and hardened but instead you seem to have got in a sulk about an entire community because they demanded you stop taking shortcuts.

Thats the thing about Free Software and Open Source. Other people can see your code and change it for the better. The communities tend to try and keep things centralised, although they dont need to and in many cases they didnt, creating a fork. Here they were telling you what the problems are. Perhaps they were wrong, Linus frequently find many who are, but here they seem to all be saying the same thing and have a point. So instead of telling them to create a fork, that would likely be better, more secure than you version, you decide to call the community toxic and quit.

Perhaps your code was toxic. Of you go now. Give the keys to the person taking over from you, maybe they will sort out the mess.

[jake]

Re: Oh dear

"Security is everything when concerning the web these days"

I think I see your misunderstanding ... "The Web" is not today, never has been, and never will be secure. In fact, the Internet itself is not secure and cannot be made secure without a complete, ground-up re-write. Anybody who thinks otherwise is deluded.

Oh dear, indeed.

[Anonymous Coward]

Huh?

"Actix Web was developed by Nikolay Kim, who is also a senior software engineer at Microsoft,"

"There is extensive use of unsafe code in Actix,"

Eh, and someone was surprised that a programmer from Microsoft used "unsafe" code? Just sayin...