6 ms·

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

• lambdaone 2y ago
  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.
  • Joel_Mckay 2y ago
    [flagged]
    • tremon 2y ago
      Polyglot projects by their very nature inject unstable dependencies into the build tree 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
      • bronson 2y ago
        > This also make the core feature of bootstrapping Linux on new hardware more difficult. 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.
        • Joel_Mckay 2y ago
          The drama started because of the core memory API argument. That day is today my friend =3
          • steveklabnik 2y ago
            You’re simply incorrect, in a way that Linus himself very clearly stated. 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.
            • Joel_Mckay 2y ago
              It was my understanding the request was to have the core maintainer take on the additional task of supporting the rust API on top of the existing wrapper. I could be wrong, but a branch or fork seems like the easiest solution. =3
              • steveklabnik 2y ago
                You misunderstood.
              • dralley 2y ago
                Your understanding is completely wrong. There was no such request, and that concern was almost immediately addressed by spelling out very directly that no such expectation existed. https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/T/#mace05a0a97522193876bb38e6f64a6ca941a59d8 https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
    • braiamp 2y ago
      And yet, the powers that be, understand that, and have reasoned that the upside of preventing new code with bugs into the kernel is way too attractive to ignore.
      • Joel_Mckay 2y ago
        [flagged]
        • imtringued 2y ago
          Linus torvalds is the biggest idealist here.
    • pjmlp 2y ago
      C already felt outdated in 1993, that is why since then I rather use C++ than C, when the choice boils down to these two languages. 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. :)
      • Joel_Mckay 2y ago
        "I rather use C++ than C" 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
        • pjmlp 2y ago
          Agreed, that is why "Exception being when there is really no way around C,..." 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.
    • marcosdumay 2y ago
      > People could have spawned another kernel branch focused around Rust 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.
      • Joel_Mckay 2y ago
        The hobby kernel I work on is only 68KiB in size, and won't work with most von Neumann machines. Probably a waste of time, but a fun odd architecture given the relative simplicity. =3
• wffurr 2y ago
  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 2y ago
    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.
• GiorgioG 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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.
• thegrim33 2y ago
  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 2y ago
    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.
• pseudocomposer 2y ago
  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 2y ago
    Is that possible? Could C add a borrow checker? Honest question, I have no idea how anything works
    • tremon 2y ago
      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 https://dlang.org/spec/memory-safe-d.html