Rust dust-up as entire moderation team resigns. Why? They won't really say The Rust language community is in disarray following the resignation of the entire moderation team, citing the "structural unaccountability" of the core development team. The moderation team, represented by Andrew Gallant, posted its resignation to GitHub yesterday, stating that it was "done in protest of the Core Team placing …
I get the suspicion there's actually something going on within the core team that the Mod team feels they should act on, but can't because Core is blocking any such action. And they're avoiding actually mentioning any of that because it's bad enough it'll make all of them look very bad.
There's 10 "teams". Most open source projects don't even have 10 people actively contributing. That's a lot of managing for what is a project which should have a fairly focused scope.
What it sounds like is a management power struggle with the losing party resigning. The Core Team are the ones who are supposed to be in overall charge, so it's no surprise that they came out on top.
We're an anarcho-syndicalist commune. We take it in turns to act as a sort of executive officer for the week,...
: ...but all the decisions of that officer have to be ratified at a special bi-weekly meeting...
: ...by a simple majority in the case of purely internal affairs,...
: ...but by a two-thirds majority in the case of more major--
I don't think 10 teams is necessarily excessive. The Rust project has many parts that need a bit different skills: defining the language itself, creating and maintaining the implementation and related tools, documenting, web site management, testing, keeping CI up, and probably some I missed. It is an uncommonly ambitious project, most other open-source projects are far simpler.
Read what most of those teams are engaged in. Most aren't touching the core language, they're working on specific areas like embedding, documentation etc.
The moderation group just appears to the ones who take care of the mailing lists, set the code of conduct, approving people, banning obnoxious people and the like.
No, moderating the communication channels. This is hardly a controversial thing to require in a large open source project. Do you think Debian, Apache or any other open source collective don't have moderators fulfilling similar roles to take care of forums, mailing lists etc?
seems to be run by a top heavy bunch of managers
The bureaucracy-speak quoted within the article was making my brain fog and my eyes glaze over.
(Yeah I THOUGHT I smelled 'bureaucracy')
All of this anal retentivity over CoC and violations and bans and @#$% makes me wanna puke my guts out (wanting very much to continue on with something along the lines of "vacuous toffee-nosed malodorous pervert" like a famous Monty Python sketch... but would THAT violate their CoC? Oh the tangled webs we weave!!!)
Then it's important enough to specifically say why, so others are aware of the actual issue, so they can fix it. You're supposedly resigning in the hopes of changing things, after all.
Otherwise it's just showboating & attention-whoring.
Just saying "the core team sucks" is not helping anything.
Saying "my manager sucks" doesn't help. Saying "my manager hogs all the credit and doesn't reward anyone on the team" is something people can do something about.
`Just saying "the core team sucks" is not helping anything.`
It's helping the ex-mods preserve their sanity and dignity in a no-win situation. If they are not being allowed to do their jobs, and will later get the blame for not having done their jobs, then it's time to walk. Or would you prefer they set themselves on fire in protest?
would you prefer they set themselves on fire in protest?
No, but there is holding a dialog to fix things, and there is constructive criticism.
On one end of the spectrum there's just pointlessly bitching and moaning, and on the other, there's actively trying to fix things.
How long do you keep trying before it's time to give up and walk away?
I'm absolutely certain they've been actively trying to fix things for a very long time. This isn't the kind of decision one takes on a whim.
From the way all this has been phrased, it's very clear that someone or someones on the core team has been breaking the rules repeatedly and has refused to follow them and/or accept censure. The mod team clearly don't want to name them for whatever reason, so are being rather careful about details as otherwise it'll be very obvious who.
You're both right, which is why the only way to address the problem is to point out the specific details and let others make up our own minds as to which point of view we ought to share. That would also help assess whatever structural or leadership changes should be made (like, should the moderation team be eliminated, or should the code of conduct be abolished, or should someone be removed from the core team, or something else). In hiding the details, the moderators forfeited the moral high ground and harmed their former colleagues by ensuring endless unresolvable controversy without offering any way to fix the underlying problem if one exists or judge for ourselves what solution might be best. It's absolutely bizarre to resign in protest while purposely refusing to shed any light whatever on what specifically you're protesting. It's a teachable moment: never do this.
"it's just showboating & attention-whoring."
Has anyone ever joined a so-called "Team"[0] formed to ensure adherence to a CoC who isn't an attention whore and showboater?
Have any of the above ever been actually useful to the product being produced, or do they impede the progress of that project?
Gibe me one halfway decent BDFL over all these cross-purpose "Teams" any day of the week.
[0] If you can hear the capitol "T" when they are talking, keep well away for your sanity's sake. It's a sure sign that the bureaucracy has become more important than the project itself.
Has anyone ever joined a so-called "Team"[0] formed to ensure adherence to a CoC who isn't an attention whore and showboater?...Have any of the above ever been actually useful to the product being produced, or do they impede the progress of that project?
On the board of a small non-profit, my responsibilities included "governance"and "board development." Basically, help the Board function effectively and responsibly, and continue to do so. This included things like ensuring that everyone on the Board understood their roles and their obligations. Getting concerns aired before they became conflicts (and before those conflicts became crises). Finding candidates that the Board could recruit. Arranging training. And yes, helping the Board and its members live up to the Code of Conduct and other legal and ethical commitments.
It was hard work supporting everyone else for very little recognition even within the Board. Total opposite of your "attention whore and showboater."
It's absolutely necessary to the final product. If your organization cares nothing for the actions and ethics of their leaders, that is whom you will attract. You'll lose the honest ones. If your organization is led by people who do not act honorably and respectfully, that cascades all the way down.
"Saying 'my manager sucks' doesn't help. Saying 'my manager hogs all the credit and doesn't reward anyone on the team' is something people can do something about"—but they didn't say "my manager sucks". They said "we were hired to moderate this place, but the managers exempt themselves from moderation" and possibly "and insist on doing some of the moderating themselves without us having a say in it", and, which wasn't repeated in the article, they offered to explain things a bit further when contacted personally.
What would you do? Stating exactly that and quit, or publicly complaining "but Steve has said this and John has said that", before quitting?
The core team is supposed to be in charge, that's fine. But just because you're in charge, that doesn't mean you're above the rules. A lot of people have died by not understanding that basic law of politics. (See Charles I of England, for instance.)
So there needs to be some kind of mechanism for addressing alleged rule breaches by the core team, or at least by individual members of that team. That's what is missing.
Crikey .... Now there's a Sp00Key Singularity and Virtual Parallel. A leaderless technocracy akin to and mimicking a vacant Prime Ministry and treacherous Presidency.
A Perfect Opportunity though for that which and/or those who know what needs to be done next for the very best of reasons on a serial basis.
Can you think of anything/anyone more suited for future presentation than any of the current constantly consistently failing traditional conventional fare?
Speak up now, for you don't often get such a chance to voice your opinion on such as be leading matters.
Sounds to me like a power struggle.
As others have pointed out above, if there is a serious enough problem that a raft of people have to resign, then it behooves them to make public at least some measure of why. Sounds suspiciously like someone threw their rattle out.
As long as key developers/designers are not resigning, then it doesn't seem like much of a loss to me.
Hmm... this mostly seems to me that someone on the "core team" is behaving badly, and no-one dares touch him/her/them because he/she/they/it are deemed "too valuable" to censure in any way.
The bottom line is that the best form of governance is always the benevolent dictator. The only snag is that finding a suitable overlord is tricky, and agreeing on what is meant by benevolence is impossible, so you either grin and bear it (hi, Linus) or you end up with these sorts of problems.
We know about the problems of dictators with unlimited power, so there should be some amount of checks and balances. Mr Torvalds always seems to apologize for occasional aggressive speech, which means there is a balance of some sorts.
Maybe Rust needs a king controlled by some kind of parliament ?
Or maybe public naming&shaming would be enough to control the Rusty King ?
Mr Torvalds certainly must answer to the corporations (such as Google, HP, IBM, Amazon) who are heavily invested in Linux.
These corporations would probably fork Linux in a whim, if they had unfixable trouble with him.
Also, FreeBSD, OpenBSD and quite a few more wait in the wings.
"These corporations would probably fork Linux in a whim"
If they could, they would have done so a long time ago[0]. But they know that if they do, they lose the free experienced help of several hundred thousand FOSS coders world-wide. Baby & bathwater.
[0] Some would say that they already partially have ... but that's another rant.
I doubt if Mr. Torvalds gives a fuck about these giant corporations.
He is comfortable enough, and they are in his thrall rather than he --- or Linux --- to them.
.
They use Linux solely because it is the best, and cheaper, solution; and Linux will outlast all those 4 --- the history of big business is littered with failures who were once massive. Which includes billion/millionaire individuals, as well as the companies, shell companies, and monopolies those leaders once ran.
https://en.wikipedia.org/wiki/Linux_Foundation#Corporate_members
Linus earns about 700k/year from these corporations, which is O.K. with me. He is a businessman-engineer who operates in a kind of cooperative setup. Like the Raiffeisen-thing in Germany or coop banks in other countries.
Just don't assume he has no overlords. Linus is an employee of all those megacorps who have pooled their efforts in the OS sector.
http://techrights.org/2020/08/16/the-linux-racket/
The real full horror story of the Linux Foundation can be read on the same site. I always thought that the big closed source players would eventually try to kill Linux and it seems it's happening, now they've extracted a lot of value from it for free in passing. And the age old method is to foment internal dissent so the enemy collapses spontaneously.
Let's hope Linux the reality outlives Linux the brand.
I think a better way of looking at it is corps know Linus is a safe pair of hands. He doesn't tolerate shit getting into the kernel no matter who is trying to land it, big or small. And while he might ruffle feathers from time to time, the long term result is a stable kernel with no major drama.
And I bet Linus would be the first to tell any corp who thought different where they could stick their money if they tried to do an end run around him.
have a mid-week beer for asking a question many ignore... Mr Torvalds has a great grip on the Kernel and is just the man (if a bit mouthy sometimes - but that is down to personal taste rather than effectiveness) for the job.
When the Kernel loses its fuhrer, what happens then?
Poettering steps up? somehow I think that would go down well /s
Interesting times for everyone I think.
I been using Linux since before 1.0 kernel and have been mostly happy with Torvald's management of the most important piece of software in the world for at least 20 years. But I do wonder what happens when he steps down or is removed. There are many interests that would like to destroy Linux and far far more who would merely like the privileged of running it despite being no-where near capable of running a whelk stall.
Its the seed corn for so many commercial interests it will be interesting to see if they can learn to co-operate on it when he goes or whether they will kill the goose that gives their daily bread a nice egg to make it palatable and nutritious. The economic cost of each having to maintain their own goose is going to be ruinous to almost all of them. Some may even feel that the socialist Linux must die and prove the pen that signs off on their harikari is indeed mightier than the sword.
"this mostly seems to me that someone on the "core team" is behaving badly"
Probably just a simple personality conflict. The moderation "Team" tried to flex their muscles ("We're charged with enforcing the CoC, so we're more equal than you are!") and were called out ... and slunk off with their tail between their legs.
Power struggle, Accountability struggle....
Sounds like the Moderator Group keeps everyone else in line, with Core actually doing the enforcement. But if Core goes off the rails, and refuses to enforce the Mods' edicts against themselves; Quis Costodet?
Core can censure Mod, Mod and Core can censure everybody; but no-one (except Core) can call Core out. That is problematical.
My best solution would be to add (yet) another group "Enforcement" or sommat, who has no investigative powers, cannot lodge complaints, they only exist to enforce censure - so they cannot go off the rails in any meaningful way. Takes the load off of Core, and also allows Core to be held accountable, while still keeping Mod from being judge, jury and executioner.
True enough, but it's all pure speculation without something concrete to hang it on.
Just upping and leaving without any kind of explanation is bound to fuel such speculation. With that in mind, you would have thought people whose job it is to manage this kind of messaging should have realised that. Just my opinion but perhaps they weren't really up to the job therefore.
This is the thing though.
These people are a group responsible for conduct and invoking sanctions against those they deem to have broken the rules. Regardless of whether they feel that they have the official authority to wield that power on an individual acting in a dickish manner, as individuals charged with such a responsibility, they could at least blow the whistle on it. The fact that they have not means either they don't have the backbone (so maybe they are completely unsuitable for the role), or there is nothing specific to report, which frankly seems more likely.
What they have done is instigate the worst possible damage on the Rust project compared to any of the other options. They have brought disrepute to the project without a shred of decency to at least uphold what they were supposed to be upholding.
Completely unacceptable.
As a language, Swift most definitely is not an alternative to Rust (memory management is different for a start). It’s also controlled by Apple, a company with a reputation for pulling important things out from under developers’ feet.
Sappeur is new to me, but reading “Sappeur combines the advantages of C ++ with the advantages of Java” is odd, as I wasn’t aware that there were any advantages to Java anymore except ubiquity (and if that’s the measure, we’d also have to say JavaScript is somehow “good”).
Despite the poor choice of comparison, what’s there looks interesting, and it’s been marked for later review. Thanks and upticked.
Java is memory safe, even (kind-of) with multithreading. C++ is not.
C++ is very efficient and semi-realtime capable even with using heap memory.
Java is not semi-realtime-capable if you allocate dynamic memory during usual processing steps.
C++ has RAII, Java has not. RAII is the most efficient way of acquiring and releasing expensive resources such as database connections, sockets and file handles.
C++ has synchronous destructors, Java has not.
Sappeur aims to merge the good things of both.
Sappeur is arguably superior to Java in ensuring multithreading synchronization of shared data access.
Java is superior in its ability to collect cycles of garbage objects, over (traditional) C++ and Sappeur. The latter two can only reclaim memory if cycles are broken by explicit code.
As a language, I actually quite like Java, but as an implementation I hate it. Enormous memory hog and I've always felt that garbage collection is a poor solution to the problem of heap memory management. Rust at least tries to fix the second problem with declarative logic through explicit life-cycle management and this is the key killer feature that has everyone keen.
Sappeur programs can be almost as tiny as efficient C programs are. They can also start in a few milliseconds, do their work and be done in another few milliseconds. Like the C based Unix userland tools. Unlike most Java VMs.
That is because a Sappeur program is in fact a C++ program with little overhead for refcounting, stack overflow and array index checks. Multithreaded programs have some Mutex checking effort. All the system libraries are thin wrappers around the POSIX or Windows APIs.
The resulting memory safe C++ code is compiled using g++ or any other moderately modern C++ compiler such as xlCr (or whatever the name is on AIX), SUN CC, VC++, Elbrus tcc,... All tested with success, not just theory.
I think Java succeeded over C++ because it's portable, had a far more useful standard library and when things went wrong you got nice stack trace. This translates into more reliable, maintainable code which in most cases is far more important to business than raw performance.
The biggest issue with Java is that Oracle's stewardship has been diabolical. The language has slowly fallen behind its rivals in terms of features & functionality and been encumbered with horrible / confusing licensing terms and other uncertainties.
I think the point some of the commenters are making is that C was designed to not have memory safety, as it was designed to work at the metal level where raw performance was critical. Basically, a unicycle versus a bicycle with training wheels. At some point, you have to insist on people who what they're doing, and if they're not available, throw up your hands and realize You Just Can't Get There From Here.
Rust is a safe language that compiles to machine code & bare metal as C or C++ can but without many of the issues baked into those languages. So it's not true to say C is unsafe because it needs to be but because 45 odd years ago they probably didn't think it a problem or didn't care.
45 years on and with the benefit of hindsight it turns out maybe we should care and Rust is a language that does without no runtime penalty.
As for the likes of Java, .NET, Python et al, those languages have succeed because runtime penalty is secondary to reliability, time to market etc. Those languages eliminates or mitigate against problems endemic to lower level languages and that's why they're used. We're also seeing some middle ground languages like Go & Swift that have some higher level language features while also compiling to native executables.
Rust is a safe language that compiles to machine code & bare metal as C or C++ can but without many of the issues baked into those languages. So it's not true to say C is unsafe because it needs to be but because 45 odd years ago they probably didn't think it a problem or didn't care.
I think they cared about correctness ... but I don't think they knew how to design rust or to write a rust compiler, I don't think the computers on on which C was expected to be run could have run a rust compiler in an acceptable time, and I don't think most programmers could have got their heads around the need for rust, nor the extra syntax you have to write to manage lifetimes &c. in a rust program.
45 years on and with the benefit of hindsight it turns out maybe we should care and Rust is a language that does without no runtime penalty.
Indeed. Rust has a number of difficulties ... but runtime performance is not one of them.
I think Java succeeded over C++ because it's portable
THAT would be a VERY good guess, In My Bombastic Opinion.
(it certainly makes sense to ME)
This particularly for GUI applications, and on platforms like Android that have traditionally used it almost exclusively for a very long time.
One thing I liked about Java was exception rippling.
Simplistically
If some code could give exceptions than all those types of exception had to be declared as thrown
Code that called that has to either handle those exceptions or declare they throw them
So great when you call a method as you know what exceptions it gives (so avoid classic dev bug in similar languages, e.g. c#, where method called & you neglected to check for exceptions) - and in Java compiler lets you know if you are not handling exceptions probably.
So its great for precise handling of different types of error (as long as people don't abuse it with catch all style logic), and great for control flow as you ae always forced to think about what exceptions you consume at a given level, and which you ripple up.
..But it had lots of things that gave me grief e.g. GUI, performance, memory, garbage collection "quirks", threading etc.. But all languages have pros and cons. It's great to choose your language, sadly in most commercial work its dictated which one(s) you will use.
.. and doing bit & byte level stuff you always had to remember it was always Big Endian irrespective of architecture you were running on (always the same endianness great for consistency, but "fun" when you are doing Java Native Interface calls of code on little endian machine that is dealing with little endian format datatypes).
I afraid I just can't take Sappeur that seriously, it's practically a hobby project. It is to C++ as TypeScript is to JavaScript, i.e. it's more of a method of enforcing design patterns rather than a new language. Also the source code is from a version of the language from a decade ago, what's on the website appears to be closed source.
1.) Indeed Sappeur is similar to TypeScript. But with enough effort, you could create a compiler that directly compiles Sappeur source into assembly code. For many reasons (both economic and engineering), this would not be wise at this point. For example, I could not create code for the Russian Elbrus CPU, as MCST keeps the instruction set secret (because Elbrus CPUs are part of sensitive government/military systems).
1.2) Some Eiffel compilers compile into C. That also works nicely.
1.3) Sappeur is definitely a language of its own. In grammar, syntax and semantics. It is *related* to C++, though.
1.4) ANY environment can be targeted from the Sappeur 3.4 compiler. From Atmel 16 bit Micrcontroller to 64 bit Mainframe processors. All you need is a halfway decent C++ compiler/code generator.
2.) The Sappeur 3.4 compiler is indeed closed source and requires a paid license of 300 Euro/developer for commercial use. It is free for non commercial use or evaluation.
2.2) SUN gave away Java for free, the entire world's corporations use it. They also gave away other great software such as StarOffice. Now they are bankrupt. Free by itself is not sustainable, check Mr Torvalds (see my other posts here) for details.
Well, if I can widen this to open source projects in general...
Software can't be used until it exists, but it won't continue to exist unless it's used.
It used to be the case that your reward for contributing to its existence was to be paid. Where that's no longer the case, people seek alternative rewards in validation or a sense of proprietorship. Unfortunately, once the software is out there, its users don't care who developed it, or how, they just want it to continue to work. Anything that threatens that continuity - such as turbulence in the development process - is simply an incentive to look elsewhere.
The trouble is that people who contribute feel they are owed something - even if it is just to have their opinions heard. But they're really not. Open source software really isn't some new nirvana, a community of wandering software artistes exchanging their expertise for alms: it's traditional software development from which the element of direct remuneration has largely been removed.
It's entirely unsurprising that this manifests itself too frequently in bitterness and rancour, but it's not exactly edifying for a process that is supposedly founded in altruism.
"it's traditional software development from which the element of direct remuneration has largely been removed."
Except when it's either a corporation developing it deliberately as open source and paying people to do it or co-development by multiple corporates who pay people to work on it. Rust seems to have started out as the first and become the second. AFAICS your description doesn't apply to Rust nor to many (maybe any) large, successful open source project.
Whereas there is some money behind Rust, the foundation is very new and the only reference I can find to scale of funding is "a two year commitment to a $1M budget". Even if that's $1M per year it's not going to fund a lot of the people who are involved.
Large successful open source projects do exist and they have funding and their funders have income streams that ultimately derive from the projects and their contributors recognise and accept their positions (whether paid or not). Not very many open source projects will find themselves reaching this stable state and the transition to it involves a lot of "letting go".
The core team, moderation team and the foundation management clearly do know why.
If it really was a storm in a teacup, then the remaining people would have gone public and buried the ex-mod team.
The fact that none of them want to say publicly indicates that it's a very serious problem within the core team. One that has the potential to seriously damage Rust, and everyone is scrambling around trying to figure out how to avoid that.
Some people are brilliant working alone, but are irascible in a group, sometimes even toxic.
In teammates, I value traits like honesty and respect towards others. And if you really want to get into it, teams do benefit from diversity. If you hire 6 people to think exactly alike, you have 1 brain with 12 hands.
I'm gobsmacked that you would claim the only measure of value is an individual's code.
If diversity is worthwhile, it will show itself in the code. "The only measure is code" and "teams benefit from diversity" are not at odds - unless the benefit is related to something other than the code.
(Analogously, the problem of consciousness: "there is an epiphenomenal consciousness that doesn't impact the material world at all." "What the hell are you materially talking about?")
The trouble with that approach is you will not see the problem until the project is already in a death spiral.
Teams like that turn into a clique full of yes-men, pushing out anyone who disagrees. After a while, nobody new wants to join the project, and the core overloads, becomes more toxic, pushes out yet more people as they burn out or have what would normally be minor disagreements.
The project then implodes and dies.
Good management and moderation is needed to avoid that spiral. Truly excellent management is needed to escape it once it begins, and such management is... rare. Although usually cheap, expensive managers tend to start the spirals then leave.
Sure, but post death spiral there will be no code written. :)
There is occasionally equivocation between "diversity is good for your development workflow" and "diversity is morally good." If something is good for development workflow, or for project health, then it should eventually pay rent in code. I feel if people want to make a point about diversity as a good in itself, they should say so, not try to justify it with vague benefits to the project. That doesn't mean that every person should be measured only by the code they write, but it does mean that it should eventually come down to the code somehow. The code is the point of the whole thing.
Depends entirely on what the purpose of the team is. If the team is there to execute whatever someone else though up, having 1 brain with 12 hands might very well be much more efficient and lead to better outcomes than having 12 different brains with 12 hands.
When it comes to any software, that which has value eventually boils down to the code and how well that code functions within the framework of the software. In that regard the measure of value of someone's output IS in that individuals code.
The moderation team is responsible for "helping to uphold the code of conduct and community standards."
Amusing as all this multiplicity of governance for a software project is, it would help to know what agitates these folk when it comes to 'conduct' --- does supporting Dr. Stallman make them wet themselves ? An uninterest in Black Lives Matter ? A refusal to sign an oath renouncing the Trump and all his works ?
.
This post has been deleted by its author
Now, why does Linus Torvalds not need a formal moderator ?
What was the benefit of "moderating" Mr Galileo ?
Most people will be shamed into "normality" if they say truly horrible things.
CoCs definitely smack of censorship. Powerful actors want to control speech and thoughts, as they did then. We should submit ?
There is, of course, an alternative. The moderation team stays in place and the core team resigns. That way the project can have a spotless reputation and only lack a product.
On the subject of the product - why on Earth does the language have "let" as a keyword? It seemed a backward step when Informix introduced it in their 4GL. After a few more decades it seems odd beyond belief.
"The moderation team stays in place and the core team resigns. That way the project can have a spotless reputation and only lack a product."
From the description of the core team ("managing the overall direction of Rust, subteam leadership, and any cross-cutting issues.") it's not clear to me that they contribute anything more than the moderation team. From their descriptions, I'd say the compiler are the real core. And many of the other teams come across as more essential to having a product than the "core team".
The Rust language community is in disarray following the resignation of the entire moderation team, citing the "structural unaccountability" of the core development team.
Once upon a time, in lands and spaces not too far away, an absolute beast of burden was stirred and swayed to break into smithereens to the chimes of myriad reports forever surfacing from deep and dark vaults of international concern and universal virtual despair that the exclusive executive elite global fiat central banking system is in disarray following the resignation of the entire SWIFT moderation team citing the "structural unaccountability" of the core Federal Reserve development team.
Have stranger things ever happened before to prove the likely provenance of such tales of fiction being entirely possible as fact no matter how many times they be thought and pimped to be highly unlikely and inflationary and inflammatory ‽ .
In your hoods and neck of the woods, do you see and feel those eddies and ebbs of tides exposing the truths and falsehoods which capture and captivate you in great service of an increasingly vulnerable and desperate unchosen few?
Maybe someone spotted the elephant, and now they're panicking. People are looking for a new Messiah. And she doesn't exist.
'But it can't have failed, it's in Rust!'
'How can it have been hacked, it's in Rust!'
'You told us if we used Rust, everything would be cheap and easy!'
'The Boeing cannot crash- it uses Rust!'
Maybe someone realised that it's a very bad idea to expect a new language to fix all the software safety problems in the world.
> Maybe someone realised that it's a very bad idea to expect a new language to fix all the software safety problems in the world.
While all languages engender frothy excitement at one time or another, there's no point extrapolating those moments into being everyone's permanent emotional state towards them.
"...disarray following the resignation of the entire moderation team, citing the "structural unaccountability" of the core development team.
Come on, that's a lot of frothy excitement so early in the language's life. I'm simply adding to the ifs, buts and maybes, just like everybody else.
I don't really give a damn about the politics. But we do get a lot of people making great claims for the language, based on a few contrived examples, it seems to me.
Until a significant piece of real-world system code (i.e. a portion of a kernel, or network stack, or other library etc., and probably that means Linux, but could be any number of real-time kernels) demonstrates Rust's advantage over C, I'm just along for the ride. Let the code speak for itself.
And by the way, I do hope Rust works! Just like everybody else.
Think I'll stick with Go.
Wanted to learn Rust for a while but I guess I won't bother now. Go might be from a nasty mega corp but at least that means they might put some support behind it for a few years, not just let the management/steering team look like a bunch of sulking teenagers more worried about who's besties with whom.
My bet is that it went down something like this:
- Core developer did something like supporting Kyle Rittenhouse being found not guilty, retweeted something written by someone that is pretty center ground but called right wing by the media,... Said that J. K. Rowling might have a point. Basically having too much too think.
- The self appointed HR department decided they didn't like it because it made them all feel unsafe and voicing your own opinions is basically the same as murder now.
- The HR department went to the Core devs with the CoC in hand, said that this opinion is disallowed by the vaguely wordly CoC that boils down to "Don't hurt my feelings".
- The Core devs said "You guys are nuts. People are allowed to think what they like. This has nothing to do with the Rust project. Stop being babies".
- And the HR department cried "BUT THE COC!!!", quit and noone noticed or cared they were gone.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
