[p0w3n3d]

> to be at least somewhat nice nowadays

That's a huge sacrifice when speaking of him, which we must appreciate. But to be honest, I must agree with his point of view.

Golden rule when developing projects is to stick to one (the least amount possible of) technology, otherwise, you'll end up with software for which you need to hire developers of different languages or accept the developers that won't be experts in some of them. I am working on a project that, up until a year ago, had been partly written in Scala. All the Java developers who didn't know Scala were doomed to either learn it in pain (on errors and mistakes) or just ignore tasks regarding that part of the system.

[lambdaone]

You're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex, and C so obviously outdated now, that it's worth the pain to start writing drivers in Rust. And because of the modularity of the kernel, and the care taken to make Rust binary-compatible with C, this looks to be actually practical, as individual subsystems will be either entirely Rust or entirely C, particularly when new drivers are involved.

[thegrim33]

At my last job at a FAANG we had an Android app in Kotlin, and in all their wisdom the management decided to jump on the hip new thing, React Native, and start coding new/certain features in React Native.

Multiple years later, what was the state of things? We had a portion of the codebase in Kotlin with dedicated native/Kotlin developers, and a portion of the codebase in RN with dedicated RN/JS developers.

Any time there's a bug it's a constant shuffle between the teams of who owns it, which part of the code, native or JS the bug is coming from, who's responsible for it. A lot of time time nobody even knows because each team is only familiar with part of the app now.

The teams silo themselves apart. Each team tries its best to hold on to the codebase - native teams tries to prevent JS team from making the whole thing JS, the JS team tries to covert as much to JS as possible. Native team argues why JS features aren't good, JS team argues the benefits over writing in native. Constant back and forth.

Now, no team has a holistic view of how the app works. There's massive chunks of the app that some other team owns and maintains in some other language. The ability to have developers "own" the app, know how it works, have a holistic understanding of the whole product, rapidly drops.

Every time there's a new feature there's an argument about whether it should be native or RN. Native team points out performance and look-and-feel concerns, RN team points out code sharing / rapid development benefits. Constant back and forth. Usually whoever has the most persuasive managers wins, rather than on technical merit.

Did we end up with a better app with our new setup, compared to one app, written in one language, with a team of developers that develop and own and know the entire app? No, no I don't think so.

Feels like pretty parallel of a situation compared to Rust/C there.

[ratorx]

Other than the choice problem of deciding what language to build new features in (which needs a clear policy), I don’t see why maintaining a mixed language codebase HAS to be terrible.

In my current job, also at FAANG, my team (albeit SRE team, not dev team), owns moderately sized codebases in C++, Go, Python and a small amount of Java. There are people “specialised” in each language, but also everyone is generally competent enough to at least read and vaguely understand code in other languages.

Now of course sometimes the issue is in the special semantics of the language and you need someone specialised to deal with it, but there’s also a large percentage which is logic problems that anyone should be able to spot, or minor changes which anyone can make.

The key problem in the situation you described seems to be the dysfunction in the teams about arguing for THEIR side, vs viewing the choice of language as any other technical decision that should be made with the bigger picture in mind. I think this partly stems from unclear leadership of how to evaluate the decision. Ideally you’d have guidance on which to prioritise between rapid development and consistency to guide your decisions and make your language choice based on that.

As your codebase scales beyond a certain point, siloing is pretty inevitable and it is better to focus on building a tree of systems and who is responsible for what. However that doesn’t absolve especially the leads from ONLY caring about their own system. Someone needs to understand things approximately to at least isolate problems between various connected systems, even if they don’t specialise in all of them.

[fingerlocks]

Out of the “FAANG” list, we can rule out Apple for obvious reasons and Amazon because it’s evident from the poor usability of their mobile apps that they have zero native code. Does Google use RN? Seems unlikely with their Flutter stack.

Was this at Meta? I doubt the iOS FB app and Insta are using RN so that must leave FB messenger?

[steveklabnik]

> I doubt the iOS FB app and Insta are using RN

https://reactnative.dev/blog/2017/08/07/react-native-perform...

> React Native is used in multiple places across multiple apps in the Facebook family including a top level tab in the main Facebook apps. Our focus for this post is a highly visible product, Marketplace.

[qchris]

While I think your points about some of the difficulties that arise in multi-language/framework projects is fair, I sort of roll my eyes whenever someone frames Rust as something like the "hip new thing".

The Linux kernel's first "release" was in 1991, hit 1.0 in 1994, and arguably the first modern-ish release in 2004 with the 2.6 kernel. Rust's stable 1.0 release was in 2015, 13 years ago. There are people in the workforce now who were in middle school when Rust was first released. Since then, it has seen 85 minor releases and three follow-on editions, and built both a community of developers and gotten institutional buy-in from large orgs in business-critical code.

Even if you take the 1991 date as the actual first release, Rust as a stable language has existed for over 1/3 of Linux's public development history (and of course had a number of years of development prior to that). In that framing, I think that it's a little unfair to include it in the "hip new thing" box.

[GiorgioG]

I've been doing this for over 20 years and it's the first I've heard of this "golden rule". I guess we've all been doing it wrong...writing our backends (pick your poison), frontends (TS/JS) and queries (SQL) in a variety of languages forever.

[jeroenhd]

I've mostly seen language mixing in frontend. Backends seem to end up either being completely ported to a new (compatible) language, or experimental new languages get ported back. Perhaps frontend developers are just more versatile because they have to, with frameworks and the base spec constantly shifting under their feet.

Even many backend devs seem to shy away from things like SQL because they're not too comfortable with it. Which isn't bad per se, it's very easy to make a small mistake in a query that crushes the database, just a personal observation of mine.

[kasey_junk]

In 30 years as a backend engineer I’ve never worked in a single language codebase.

The idea that there is some rule that you don’t mix languages seems like absolute nonsense. If someone suggested to me that it was _possible_ I’d be extremely curious what wild tradeoffs they were making to get there.

[jeroenhd]

I think it makes sense to have a preference for a single language in code bases when all of your developers only have one language in common and are not interested in learning any more languages in the future. That doesn't necessarily make it a golden rule.

However, in my work I've seen plenty of developers with all manner of interests and experiences align only on one or two languages, and if that's your company's talent pool, single language code bases seem like a good idea.

Of course this skips over all the usage of scripting languages (makefile/bash/Python/XML) which in my experience are seen as quirks of build tooling rather than part of the product.

[QuadmasterXLII]

There’s also complementary vs competitive: C++/python (pytorch, itk, ROS) or Go/js (default web stack) aren’t going to quibble over what belongs in what language- react/swift or c/rust codebases have no such natural partition

[toyg]

> Perhaps frontend developers are just more versatile

Considering that they'll want to use Node even to make coffee, I'd argue that statement is wildly inaccurate.

[josefx]

And if you look how that mess started out you had cross site scripting on the frontend because html allowed you to inject more javascript from everywhere and SQL injection on the backend because you had to translate your input from one language to another with tools that went out of their way to interpret data as commands.

The modern web is a gigantic mess with security features hacked on top of everything to make it even remotely secure and the moment it hit the desktop thanks to electron we had cross site scripting attacks that allowed everyone to read local files from a plugin description page. If anything it is the ultimate proof how bad things can go.

[mamcx]

And the people like me that work in ERP's/bussines apps have even more langs.

I have used around 20+ in my little project (mostly solo) and I have now:

* Rust

* Kotlin

* Swift

* Html

* Sql with variations for: Postgres, Sqlite, Sql Server, Firebird, DBISAM, MySql

* Go

* FreePascal

And now is when I have less languages.

People are flexible.

[pjmlp]

Double that, I think the only time I was single language developer was when Timex 2068 BASIC was the only programming language I knew.

[wffurr]

Is that really a “golden rule”?

I have worked on lots of cross language codebases. While it’s extremely useful to have experts in language or part, one can meaningfully contribute to parts written in other languages without being an expert. Certainly programmers on the level of kernel developers should readily be able to learn the basics of Rust.

There’s lots of use cases for shared business logic or rendering code with platform specific wrapper code, e.g. a C++ or Rust core with Swift, Kotlin, and TypeScript wrappers. Lots of high level languages have a low level API for fast implementations, like CPython, Ruby FFI, etc. The other way around lots of native code engines have scripting APIs for Lua, Python, etc.

[w0m]

I don't know if its golden rule or common-sence when applicable.

If our testing framework is in Python; writing a wrapper to code tests for your feature in Perl because you're more comfortable with it is the Wrong way to do it imo.

But if writing a FluentD plugin in Ruby solves a significant problem in the same infra; the additional language could be worth it.

Everything is about tradeoffs.

[pseudocomposer]

I’d argue that number of languages is less critical than how well-supported/stable the languages/frameworks chosen are, and whether the chosen tools offer good DX and UX. In simple terms… a project using 5 very-well-supported languages/frameworks (say, C, Rust, Java, Python, modern React/TS) is a lot better off than one with 3 obscure/constantly-shifting ones (say, Scala, Flutter, Groovy).

Anyway, I’m a bit of a Rust fanboy, and would generally argue that its use in kernel and other low-level applications is only a net benefit for everyone, and doesn’t add much complexity compared to the rest of these projects. But I could also see a 2030 version of C adding a borrow checker and more comparable macro features, and Rust just kind of disappearing from the scene over time, and its use in legacy C projects being something developers have to undo over time.

[chamomeal]

Is that possible? Could C add a borrow checker? Honest question, I have no idea how anything works

[jcranmer]

C takes backwards compatibility quite seriously, so anything it adds has to be opt-in (not that it stops some people from trying to propose seriously breaking changes, but c'est la vie).

Something like a borrow checker can be added (and there are people on the C committee willing to see it). However, Rust's "shared xor mutable" rules are probably too strong for C, so you'd need to find some weaker model that solves a good deal of memory safety issues (maybe expressing pointer ownership and some form of invalidation is sufficient, but this is just some spitballing by me). The focus by the interested people right now is mostly around bounds-checking rather than a borrow checker.

[steveklabnik]

In theory, they could. In practice, I would be shocked. As an example, Rust's memory safety rules are fundamentally built on top of generics, which C does not have. So in order to copy what Rust does, they'd need to do that first, and that's a massive change to the language.

C++ does have generics already (well templates, but you know) and so it'd be an easier lift there, but it's still a lot of work. https://safecpp.org/draft.html explains how this would be possible.

[porridgeraisin]

> Could C add a borrow checker

As I understand it, doing it while maintaining compatibility with old code is not possible. You'd have to add new required syntax for annotations and such.

[tremon]

Not really possible, I think. C is a language that's basically built on memory aliasing and pointer arithmetic: every variable is represented as a location in memory, but there is no guarantee that each memory location is only represented once (there can be many variables pointing to the same memory address). The Rust borrow checker needs pretty much the opposite guarantee: every declared variable has full control over its memory location, and if two pieces of code need to share memory there needs to be an explicit protocol for delegating access.

And it's not like pointers are a rare occurrence in C. This mechanism is used pretty much everywhere: accessing array values, parameter pass-by-reference, function output parameters, string manipulation. There's no concept of function purity either, so no way to guarantee in the function definition that a function cannot outstep its bounds. Sure, there are certain safe coding conventions and rules about what you can or cannot do in a C program, but fundamentally proving that a certain memory location is only accessed through a certain variable is only possible by just running the program exhaustively -- or by confining yourself to a subset of C.

But when you only allow a subset of C, it's no longer "C with a borrow checker", especially given the ubiquitous use of pointers for standard language features. It quickly becomes "we hobbled C because we need more guarantees". To take a quote from the D manual [0], to guarantee memory safety you need to disallow:

  - Casts that break the type system.
  - Modification of pointer values.
  - Taking the address of a local variable or function parameter.

[0] https://dlang.org/spec/memory-safe-d.html

[steveklabnik]

> C is a language that's basically built on memory aliasing

Additionally, C does actually have aliasing rules, but many projects, including the kernel, turn them off. Linus in particular does not think they're worthwhile.

These rules are different than Rust's, Rust also rejected these particular rules.

> To take a quote from the D manual [0], to guarantee memory safety you need to disallow

Just to be clear, this is the list for D, not in general. Rust is fine with you taking the address of a local variable or function parameter.

[tremon]

> C does actually have aliasing rules

If you're referring to e.g. gcc's -f[no-]strict-aliasing option, then that's more about type compatibility than about limiting the scope of memory aliasing in general. If you mean something else, I'm interested to hear more.

> this is the list for D, not in general

Yes, I know. But it's the first authoritative source I could think of on memory safety in C-like languages. I don't think the list is wrong for C proper, just probably not exhaustive.

> Rust is fine with you taking the address of a local variable

Yes! But circling back to the earlier point: in Rust you can do this specifically because the language has well-defined lifetime semantics on variables and ownership. And as such, Rust can guarantee that a) a pointer to a memory location does not outlive the scope of the memory allocation itself, and b) when two variables/pointers refer to the same memory location, there is a compiler-enforced protocol for accessing and mutating that memory.

[steveklabnik]

> then that's more about type compatilibity than about limiting the scope of memory aliasing in general.

It's about limiting the ability of pointers to alias. The C standard even has this parenthetical:

> The intent of this list is to specify those circumstances in which an object can or cannot be aliased.

You are correct that it's a pretty narrow set of rules. There are only six items on that list. But it's still an aliasing rule.