[flagged]
What does this mean?
This also make the core feature of bootstrapping Linux on new hardware more difficult.
If by this you mean that Rust doesn't support all the architectures that gcc does:
- that didn't stop people from making sure Linux could be compiled with LLVM as well
- gccrs should make this issue moot anyway, as that will allow Rust code to be emitted for exactly the same architectures as gcc proper
No, Rust is currently only for drivers that aren't on that hardware anyway. You can continue to build and use the kernel without Rust just fine.
For now... Maybe one day that discussion will become relevant.
That day is today my friend =3
The drama started because Rust used an API written in C. It doesn’t contain any Rust at all. Nothing has changed in this regard.
I could be wrong, but a branch or fork seems like the easiest solution. =3
https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
In general, mixing languages has serious long-term consequences. Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully.
Perhaps ask why folks didn't create an isolated kernel branch for such a massive refactoring?
"Rust doesn't support all the architectures that gcc does"
Assuming a bootstrap compiler can even bring up Rust or the cargo monstrosity. People will just switch to other options, and maybe someone will get around to a Rusty Linux Fork if the working system needs entertaining drama.
Best of luck =3
The reason I don't understand fully is because you don't explain yourself. I'm not convinved it has anything to do with my work experience.
I can see how that could be challenging, but some lessons are universal. This talk touches on the problem at an organizational level:
https://www.youtube.com/watch?v=GWgRw5jiYy0
Best I can do for you right now. Good luck =3
Most folks can disagree on things, and remain respectful. Have a glorious day =3
Polyglot projects are harder, but definitely not as hard as OS development in C.
The majority of companies doing web is doing "something plus Javascript".
And then if there's some AI in the mix, there's also almost always Python. Often maintained by a super small team.
What about apps? Java and Swift. The migration to Swift included a lot of Obj-C and Swift living side by side for a while. Same with some apps migrating to Kotlin.
Apps are in user space, and are often disposable-code after 18 months in most cases. Projects like https://quasar.dev/ offer iPhone/Android/iOS/MacOS/Win11 single code base auto-generated App publishing options, but most people never hear of it given a MacOS build host is required for coverage.
The talk pokes fun at the Ivory tower phenomena, and how small-firm logical assumptions halt-and-catch-fire at scale. =3
I think that you are handwaving away differences in runtime environments. All languages (almost) are Turing-conplete. Many of them, if used in the wrong context, will get you stuck in a Turing tarpit.
Languages succeed or fail on the strength of their runtimes. If you seriously think that mixed-code codebases are trash after 18 months, then I think I'm wasting my time - that statement is so fundamentally detached from reality that I don't even know how to start.
It is the statistical average for Android, but again it depends on the use-case situation. Apps are a saturated long-tail business that fragmented decades ago.
Python sits on top of layers of C++ wrappers for most ML libraries, and doesn't do the majority of the heavy computation in Python itself (that would be silly). Anyone dealing with the CUDA SDK for Pytorch installs can tell you how bad it is to setup due to versioning. That is why most projects simply give up to use a docker image to keep the poor design dependencies operational on a per project basis.
"then I think I'm wasting my time"
Than just let the community handle the hard part, and avoid having to figure it out yourself:
https://github.com/dambergn/ai-stack
I think you are confusing ML work with end users playing with other peoples algorithms.
Best of luck =3
Single-language codebases are the exception rather than the rule in a lot of industries, which includes apps and web. Ditto for operating systems: the Linux Kernel might be majorly C, but both Windows and Mac mix C and C++ in the kernel but a lot of userland is in C#, or a mix of Swift and Objective-C.
Probably conflating popularity with good design. The talk covers the financial incentives for naive code choices, and perceived job security in ivory towers.
It might work for you, but in general is bad for the firm long-term. Best of luck =)
And sorry but the other half of your message has nothing to do with what I wrote.
And indeed >52% of those Polyglot projects end up failing in more than one way, and are refactored or abandoned. I didn't like that the talk rips on Elixir/Phoenix either, but factually his insights were not inaccurate.
On average it takes around 2 to 3 years to understand why... As it takes time to see why Tacit knowledge is often ephemeral. Tantalizing bad ideas reverberate on the web, and the naive recycle them like facts. YMMV and it usually doesn't matter if you have under 38k concurrent users... and spend $3m/month in transfer fees to AWS. Perhaps your part of the world works differently than mine. =3
https://en.wikipedia.org/wiki/List_of_Google_products#Discon...
"definitely not as hard as OS development in C"
Depends what you are doing, as complexity is often a sign of poor communication.
https://en.wikipedia.org/wiki/Conway%27s_law
The talk pokes fun at the excuses folks make when kludging something they intended to replace later. =3
Complexity is a consequence of dealing with the real world. An OS talks to hardware, which might have errata or just straight up random faults.
Indeed, on average 52% of all IT projects at any firm end up failing, or were never used as designed. What exactly does a glorified marketing company have to do with successful OS design? The internal Android OS they planned to replace Linux with was canceled too. "All software is terrible, but some of it is useful" =3
Have a good day!
So you think they publish free services out of charity? Perhaps the technology business is not for you...
Best of luck =3
I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler.
This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards.
We can't have it both ways... Best regards =3
¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3
Exception being when there is really no way around C, like UNIX clones related development, or some kinds of embedded development.
Even when using TypeScript, we sometimes have to occasionally get dirty with JavaScript. :)
Depends what you are building, as some language specific features make specific tasks more difficult.
Unfortunately, often we must deal with the infrastructure we are given. =3
The first startup I worked on, back in the crazy 2000's, we were replicating AOLServer at our own way, and all the Tcl extension modules were written in C, because multiple reasons, including writing portable C across several UNIX variants was already complicated enough, e.g. the HP-UX aC we were using was still not C89 compliant, no need to add C++ into the picture.
Linus already decided his one will be a mixed-languages fork. You are perfectly free to fork your own C-only kernel and maintain it.