Hacker News Reader

Comment by Joel_Mckay | Hacker News Reader

"What does this mean?"

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

View on HN

Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully.

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'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

Just stop with the sarcasm, it doesnt belong here.

The talk covers how polyglot projects tend to fail.

Most folks can disagree on things, and remain respectful. Have a glorious day =3

Except... Most companies offer products built in multiple languages. Google notoriously has a multilingual monorepo and a uniform build system. Every company of non-trivial size uses multiple languages. Even Asahi Linux does!

Polyglot projects are harder, but definitely not as hard as OS development in C.

Yep. Even small companies.

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.

In general... it is often a skill issue with labor pools, as firms accepted Java/JavaScript is almost universally known by juniors.

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

https://en.wikipedia.org/wiki/Ivory_tower

How the can it possibly be an issue with the labor pool when JS is the only truly supported web language and Python is the main language for ML tooling?

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.

"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

Sorry but apps being disposable and "JS-only frameworks" existing doesn't change reality. Nor do juniors only knowing only one language.

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.

"Explanations exist; they have existed for all time; there is always a well-known solution to every human problem -- neat, plausible, and wrong." ( H. L. Mencken )

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 =)

Please don't put words in my mouth. I'm not conflating popularity with good design, in fact I haven't said anything of the sort.

And sorry but the other half of your message has nothing to do with what I wrote.

"Single-language codebases are the exception rather than the rule in a lot of industries"

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

Not sure employee attrition rates and canceled project metrics are a positive aspect of Google.

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

Google does not cancel projects because they're technically unwieldy, and if you ask pretty much any ex-Google engineer what they think about internal tooling they will generally praise it because it's very good.

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.

Googles initial technological success was due to the design assumption individual systems were never reliable, and should fail back gracefully. It was and still is considered a safe assumption...

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

I would suggest actually reading what engineers who have worked at the company say about it. Many of these statements you've just made are irrelevant or factually incorrect (e.g. Fuschia might be cancelled, but Google remains one of the major contributors to Linux and is certainly not a "marketing company.")

Have a good day!

'certainly not a "marketing company."'

So you think they publish free services out of charity? Perhaps the technology business is not for you...

Best of luck =3

The kernel doesn’t use Cargo, by the way.

Indeed, its actually worse because "x.py" has a lot more dependencies. lol =3

The kernel doesn’t use or interact with x.py either. The Rust code uses build to drive rustc, just like the rest of the kernel.

I think you are operating under the assumption a fully compatible cross-compiler environment is already available in both languages. =3

Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.

Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good.

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.

Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break.

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.

'It “creeping in” to something Rust can’t support won’t happen'

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

"If you want to write a driver for a platform Rust doesn't support, just write it in C."

¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3

Reply on news.ycombinator.com