Trio of Rust Core Team members take their leave There is only drama in the open source community when the day has a "y" in it, and sure enough a trio of members have decided to step back from the Rust Core Team, including a nine-year veteran of the language. It has been a busy few months for the Rust project. The entire moderation team quit in November 2021. The resignation …
Doesn't really seem like drama to me, just people leaving to work on their own thing. I'm sure the only reason they mentioned it wasn't due to the moderation team leaving was because otherwise those desperate to see drama everywhere would claim it was (though I'm sure they still will because mmm drama... delicious)
Anyone wanting to work on an open source project these days finds themselves up against militant social just warriors who have no interest in the project, but spend every minute of the day scrutinising the posts of contributors for gender specific pronouns and colonising language. It's no wonder people want to do something else.
'
Naahh, I find this part more influential: "Founding members of the Rust Foundation (kicked off in 2021) include Microsoft, Google and AWS."
Once something turns corporate, especially with any of those 3 names, people are either working for free or being worked well past what they're being paid for. Any of those 3 names are known for poisoning for their own profit, they're FOSS pirates, they do what the old Napster did while making the old Napster look angelic. Sadly in this case, there's 3 pirates and who knows how long it will be until they strip the ship. RUST... it's going to be poetic irony what that name comes to mean.
The C programming language started off very corporate. However, C was born and jettisoned from the corporate world, while RUST is being absorbed into the corporate world.
Good luck to these 3 developers.
I would REALLY like to know how you managed to justify injecting your personal political bias into a discussion that did not bring up politics in any way??
Not even the directly-linked official post, stating the reasons for the departures, mentions ANY form of politics causing these actions, yet you confidently impose your views on this topic upon the debate.
IKR! You add one tiny little (and actually hilarious) rape joke to a PR and everyone gets upset!
Just because I think people with a different skin colour are less important than people with my skin colour people don't want to work with me? And they expect me to censor myself in my daily interactions with people!!!!!
No, social justice warriors, I'm a bigot and proud!!
This post has been deleted by its author
> Anyone wanting to work on an open source project these days finds themselves up against militant social just warriors who have no interest in the project, but spend every minute of the day scrutinising the posts of contributors for gender specific pronouns and colonising language.
I have no idea if that is / was the case in Rust but I've certainly seen it in NodeJS. There was literally someone whose entire "contribution" to the project consisted of berating people for saying "hi guys".
You're peeking into the sausage factory, not into the state of the language. Don't read too much into it, yet. Going through convulsions and growing pains is a part of every successful language's heritage, not just the unsuccessful ones.
(Of course, "I was thinking I should take a look at it" sound like one of those pub pronouncements that's made year in and year out, no matter what the case is.)
Instability in the team is much less important than instability in the language itself.
I love Python but it changes too damned often. Accidentally use a new feature and it breaks your code on older run-times. If Rust doesn't change because it's lost some developers, that's a Good Thing. As long as there's somebody around to fix critical security bugs, we're good.
"I think he quite likes the idea of Rusty modules."
Not really. He use words like "we might" and "maybe we will" and "perhaps rust" and "eventually", and "drivers, probably" etc. etc. Nowhere does he say "Let's do it" or "We are going to" or "It will be soon".
He also is on record as saying ""I don't think Rust will take over the core kernel, but doing individual drivers (and maybe whole driver subsystems) in it doesn't sound entirely unlikely." ... but again, he's not entirely enthusiastic. He has also said "It might not be rust", which to me is a death knell.
I;ve been reading the LKML for as long as it;s been around, and from my perspective it looks like Linus isn't really interested in any language that isn't C for kernel use ... not C++, just good old C ... and seeing as Rust is a replacement for C++, not C ,,, well, do the math.
I think he's throwing the yowling, baying fanbois a bone just to shut them up. We might get a few drivers & the like written in rust over the next few years, but the vast majority of the kernel will still be in C long after the next language du jour takes the place of rust in the fanboi's fancy.
Everybody's a fan when the language is new and promising. They all become critics when it's time to use it for real work.
Today's new language feature may be tomorrow's regrets. Think of all the times C, C++, Ruby, Scala, Java, and others have suffered from ambiguous compilation and needed some extra declarations to fix it. Lots of these cases are no longer "bugs" because they're now documented like it was on purpose. PHP and Python don't even bother with forwards compatibility. Then there's Golang that sticks to its ideals to such an extent that it's often impractical to use. Yeah, I'd need to get paid a lot to properly maintain a software development language. It's hard.
> Then there's Golang that sticks to its ideals to such an extent that it's often impractical to use.
The ideals of Golang are "simplicity", "readability", "maintainability" and "consistency" aka. "no surprises".
How does any of that make a language "often impractical to use"?
Have a look at this comparison of languages doing a very basic hello-world like task, and tell me what stands out about the RUST version:
https://www.raspberrypi.com/news/multilingual-blink-for-raspberry-pi-pico/
I like Rust and I am actively doing more and more of it when I have time to spend learning, but this is a bit of an eye opener.
Edsgar Dijkstra of 'Goto Considered Harmful" fame (and more importantly less famous for Dijkstra complexity, the Dijkstra algorithm, and his proof that recursions can be compiled into loops) said that it is almost impossible to teach someone how to write good code who had previously been exposed to BASIC.
Maybe that's why?
"said that it is almost impossible to teach someone how to write good code who had previously been exposed to BASIC."
Sounds like a right pretentious wanker.
Computer languages exist to explain to other humans what we've told the computer to do. Ones that are difficult to parse are, by definition, shit.
You mean 75% of the Rust code being initializing and setting up the HAL environment so your logic can remain the same if you swap RP2040 boards? Not worth it in this case, since the logic is so small, but have a larger thing to do and you can port it by just swapping values on the "bloat" section.
Write well, write once.
Haha, that was quite fun to see.
I *believe* the issue is that Rust code is not using anything outside of standard library. No easy wrapper library for example unlike the wiringPi stuff.
Ultimately trying to get python to communicate directly with GPIO would be a lot of frigging around in /sys/devices/system/**
I think Rust code size is *usually* quite similar to C++ due to all the RAII design considerations.
That's an API comparison only, and some of those APIs suck. Complex code is the real test of a language.
Is it easy enough to read and write? Does it do only what it looks like it does? Does it run efficiently? Can it handle expected and unexpected errors well? Can it be maintained?
I have languages that I strongly prefer but I'd never use them for everything because nothing is perfect. There are some that I'll avoid in almost all situations because I think there are better ways: Perl, PHP, Golang, C, Objective-C, Scala, POSIX shell, and some Enterprise Edition styles of Java.
I don't have much experience with Rust but I'd consider it.
C is a systems language. A systems language is relatively niche. It has very specific requirements, which are less important for general purpose applications. In serious, critical applications, it should only be used by people who know what they are doing.
Taken from the link below, the story told by Dennis M. Ritchie:
"By early 1973, the essentials of modern C were complete. The language and compiler were strong enough to permit us to rewrite the Unix kernel for the PDP-11 in C during the summer of that year. (Thompson had made a brief attempt to produce a system coded in an early version of C—before structures—in 1972, but gave up the effort.)"
History shows that C developed alongside a real-world, large, complex, ultra reliable, system application: Unix.
I think there's a lesson there for Rust.
It's interesting that Unix was a direct counterblast to Multics (hence the name) and in terms of having a "language alongside" they both developed on very similar paths - in the case of Multics the language was (roughly) PL/I. There's some very interesting stuff here about the bootstrapping processes for the compiler.
I've not tried writing serious Rust code in anger, but my initial impression is that is falls between two stools: on the one hand it's trying to have many of the features of LISP or JVM/.Net languages, but without the convenience that comes from the managed environment and garbage collection, and on the other it doesn't directly have the language constructs for dealing with hardware directly. That doesn't mean you can't extend its capability in either direction with macros and compiler directives buried in carefully-crafted crates - but at the cost of a very steep learning curve. I don't see that it makes simple things better or hard things easier.
Linux is, bit by bit, being rebuilt in Rust. Probably never will be entirely. Microsoft is using it in a handful of projects. But that's the beachhead it lives on with just like C did with Unix, and it's probably not unreasonable to wonder if the recent shakeups in Rust are entirely due to the people actually taking it seriously and weighing in on it.
Many years ago Ian Malcolm gave a lecture to an ICL engineers conference about the successful implementation of a multiple currency and VAT POS system. To demonstrate some of the potential pitfalls he said something like "With C you can shoot yourself in the foot. With C++ you can blow your leg off".
The memory unsafe C language is a key reason for the existence of the Cyber War Domain.
The Algol mainframes that already existed in the 1970s were more robust than Unix, but also more expensive. The el cheapo approach won.
http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
A neighbour is looking for a career change from his long working hours as a chef. He has been told that self-learning with the Odin Project will allow him to get a well paid job as a web designer in about a year of part-time study.
He reeled off a list of the things he will have to master in that year: HTML; Javascript; Java; Ruby; Ruby on Rails; Rust... and also some DB things.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
