Unlurker

Stop Breaking TLS (markround.com)

I largely agree with the author. When our SOC wanted to implement TLS inspection I blocked it. Mostly because we not nearly at the security level for this, but also because it just fucks with so many things. That said, we are not a business dealing with highly sensitive data or legal responsibilities surrounding data loss prevention. If you are a business like that, say a bank or a hospital, you want to be able to block patient / customer data leaving your systems. You can do this by setting up a regex for a known format like patient numbers or bank account numbers. This requires TLS inspection obviously. Though this makes it harder to steal this data, not impossible.

Complains about TLS inspection, yet fronts their website on the biggest and most widely deployed TLS introspection middle box in the world ... Why do we all disdain local TLS inspection software yet half the Internet terminates their TLS connection at Cloudflare who are most likely giving direct access to US Intelligence? It's so much worse as it's infringing on the privacy and security of billions of innocent people whilst inspection software only hurts some annoying enterprise folks. I wish we all hopped off the Cloudflare bandwagon.

Got acquired by a Fortune 500 and recieved new laptop. First hour I'm seeing TLS errors everywhere except the browser. They'd half-baked their internal CA rollout, so wasn't trusted properly. By day two I started validating their setup. The CA literally had a typo in the company name, not a great sign. A quick check with badssl.com showed that any self-signed(!) cert was being transparently MITM'ed and re-signed by their trusted corporate cert. Took them 40 days to fix it. Another fun side-effect of this is that devs will just turned off TLS verification, so their codebase is full of `curl -k`, `verify_mode = VERIFY_NONE`, `ServerCertificateValidationCallback = () => true`, ... Exactly the thing you want to see at a big fintech company /s

Our cyber team have installed zscaler on most people's laptop, and somewhere in the fabric of the office internet connection.[1] For those that don't know, its a MITM proxy with certificates so that it can inspect and unroll TLS traffic. ostensibly its there to stop data exfiltration, as we've had a number of incidents where people have stolen data and sent it to competitors. (our c-suite don't have as much cyber shit installed, despite them being the ones that are both targets more, and broken the rules more....) Now, I don't like zscaler, and I can sorta see the point of it. But. Our cyber team is not a centre of technical excellence. They somehow managed to configure zscaler to send out the certs for a random property company, when people were trying to sign into our VPN. this broke loads of shit and made my team (infra) look bad. The worrying part is they still haven't accepted that serving a random property company's website cert instead of our own/AWS's cert is monster fuckup, and that we need to understand _why_ that happened before trying anything again. [1] this makes automatic pen testing interesting because everything we scan has vulnerabilities for NFS/CIFS, FTP and TCP dns.

Companies know that it's important to have Cybersecurity™. A vendor shows up with shiny brochures, and company is happy to purchase Cybersecurity™. Now they don't have to worry about it anymore, they bought a product that sits in the corner and delivers Cybersecurity™

Honestly, the author is spot on about the normalisation problem. I've watched this play out at multiple organisations. You implement TLS inspection, spend ages getting certs deployed, and within six months `curl -k` is in half your runbooks because "it's just the corporate proxy again". He's also absolutely right about the architectural problems too, single points of failure, performance bottlenecks, and the complexity in cloud-native environments. That said, it can be a genuinely valuable layer in your security arsenal when done properly. I've seen it catch real threats, such as malware C2 comms, credential phishing, data exfiltration attempts. These aren't theoretical; they happen daily. Combined with decent threat intelligence feeds and behavioural analytics, it does provide visibility that's hard to replicate elsewhere. But, and this is a massive but, you can't half-arse it. If you're going to do TLS inspection, you need to actually commit: Treat that internal CA like it's the crown jewels. HSMs, strict access controls, proper rotation schedules, full-chain and sensible life-span. The point about concentrated risk is bang on, you've turned thousands of distributed CA keys into one single target. So act like it. Run it like a proper CA with proper key signing ceremonies and all the safeguards etc. Actually invest in proper cert distribution. Configuration management (Ansible/Salt/whatever), golden container base images with the CA bundle baked in, MDM for endpoints, cloud-init for VMs. If you can't reliably push a cert bundle to your entire estate, you've got bigger problems than TLS inspection. Train people properly on what errors are expected vs "drop everything and call security". Document the exceptions. Make reporting easy. Actually investigate when someone raises a TLS error they don't recognise. For dev's, it needs to just work without them even thinking about it. Then they don't need to work around it, ever. If they need to, the system is busted. Scope it ruthlessly. Not everything needs to go through the proxy. Developer workstations with proper EDR? Maybe exclude them. Production services with cert pinning? Route direct. Every blanket "intercept everything" policy I've seen has been a disaster. Particularly for end-users doing personal banking, medical stuff, therapy sessions, do you really want IT/Sec seeing that? Use it alongside modern defences. ie EDR, Zero Trust, behavioural analytics, CASB. It should be one layer in defence-in-depth, not your entire security strategy. Build observability, you need metrics on what's being inspected, what's bypassing, failure rates, performance impact. If you can't measure it, you can't manage it. But Yeah, the core criticism stands though, even done well, it's a massive operational burden and it actively undermines trust in TLS. The failure modes are particularly insidious because you're training people to ignore the very warnings that are meant to protect them. The real question isn't "TLS inspection: yes or no?" It's: "Do we have the organisational maturity, resources, and commitment to do this properly?" If you're not in a regulated industry or don't have dedicated security teams and mature infrastructure practices, just don't bother. But if you must do it, and plenty of organisations genuinely must, then do it properly or don't do it at all.

The fact that most tools have completely different ways to allow them to add certificates is the biggest pain. Git, Python and Rust also have large issues. Git doesn't default to "http.schannel". Python (or rather requests, or maybe urllib3) only looks at its own certificate store, and I have no idea how Rust does this (well, I use uv, and it has its own problems - I know about the --use-native-tls flag, but it should be a default at the least).

I have this similar gripe when it comes to http proxy configuration. It's invisible to you until you are in an execution environment where you are mandated to use the providers proxy configuration. Some software reads "expected" env variables for it, some has its own config or cli flags, most just doesn't even bother/care about supporting it.

And many things break in different, exciting ways. For example, we discovered that whilst the JVM can be configured to use system certificate store, that does not apply to websocket connections. So the product seems to be able to connect to the server, but all socket connections bork out with TLS errors. Fun! And so many of those products deliver broken chains, and your client needs to download more certificates transparently ( https://systemweakness.com/the-hidden-jvm-flag-that-instantly-fixes-ssl-errors-10f27c1dffe7 ) Double the fun!

I agree with the sentiment, but I think it's a pretty naive view of the issue. Companies will want all info they can in case some of their workers does something illegal-inappropiate to deflect the blame. That's a much more palpable risk than "local CA certificates being compromised or something like that. And some of the arguments are just very easily dismissed. You don't want your employer to see you medical records? Why were you browsing them during work hours and using your employers' device in the first place?

In Europe they prefer not to go to jail for privacy violations. It turns out most of these "communist" regulations are actually pretty great.

It's definitely annoying if you work in enterprise, but on the flip side: the fact that these enterprise requirements exist is the main reason that TLS certificate configurability is possible at all, without which it would be dramatically harder (or impossible) to reverse engineer or do security & privacy research on mobile apps, IoT, etc etc etc. Enterprise control over company devices and user control over personal devices are not so different. A few apps do use certificate pinning nowadays, which creates similar problems, but saying "you can never add your own MitM TLS cert" is not far from certificate pinning everything everywhere all the time. Good luck creating a new home assistant integration for your smart airfryer when you can't read any of the traffic from its app. Imo: let's make it easier! Standardize TLS configuration for all tools, make easy cert configuration of devices a legal requirement (any smart device sold with hardcoded CA certificates is a device with a fixed end date, where the CA certs expire and it becomes a brick), guarantee user control over their own TLS trust, and provide good tools to check exactly who you're trusting (and expose that clearly to users). Not really practical of course (and opens all sorts of risky games with nation state interception as well) but there are upsides here as well.

Author here, hi! Was just venting last night, but that's a very good point, I'll update it later with your correction :)

You should make it about CT logs. I believe you need to compromise at least three of them.

↙ time adjusted for second-chance

Are We over the "Jaws Effect?" (nautil.us)

Diver and conservationist Cristina Zenato showed another side to sharks: they come to her to have hooks removed from their mouths... https://youtu.be/G8LmxwOgBhA If that's real, and not anthropomorphized, it shows that sharks are complex creatures, not mindless predators. And it also tragically shows how much damage we humans do to the natural world. Sport fishing? Not so much for the fish...

Even if you don't anthropomorphize (if that's possible) - shark actual behaviour is miles apart from the stereotypes. Imagine if shark outer appearance were more mammal-cute, but they'd kept their behaviour - they'd be cuddly super stars with a stellar reputation!

That video speaks to shark behavior, but equally as much to Zebato's risk tolerance. She seems a little too close for comfort to Timothy Treadwell https://youtu.be/watch?v=uWA7GtDmNFU

Hm, I don't get those vibes at all .

> But when I offer to teach somebody to surf, sharks are still one of the most common objections (it's probably second to "I can't swim"). It could also be just a good common excuse (and also a cover for the sometimes embarrassing "can't swim")

Huh, that’s a really good point. I wonder if that is what’s happening, will have to pay more attention next time. Thanks for suggesting it!

A woman got bitten by a shark pretty bad down the street from me about a mile away when I lived there: https://abc7.com/post/newport-beach-shark-bite-victim-recovering-from-surgery/1364668/ I understand they are out there, I understand there is an ecosystem and they are important to that ecosystem... all that goes out the window when you see a great white cruising through the water. We're cool as long as they are out at sea and not where I'm at.

What was the shark doing in the street?!

It was one of these guys: https://en.wikipedia.org/wiki/Street_Sharks

So, one chomping a week. Pretty regular.

Any average would seem regular. One chomping at a given interval. But we don't know from the average anything about regularity. Maybe all 47 chomps were in the last few weeks, maybe not. One is regular the other is irregular. /stupid nitpick

'Source available' is not open source (and that's okay) (dri.es)

I think the proper litmus test for these newfangled source available licenses is if the company is willing to operate under the terms of the license, or are they carving out special position for themselves as the copyright holder. In almost all cases I've seen it is more of the latter, and I find that pretty telling.

Why haven't anyone randomly generate a bunch of code of various kinds, use LLM to create some summary of it and dump them to github with a restrictive license? The patent office isn't here to enforce anything.

It'd be like copyright trolling the Library of Babel. The set of useful programs would be totally eclipsed by incoherent gibberish (even if there were a means to ensure that the randomly generated code were syntactically correct). In other words, the signal to noise ratio would be microscopic and running this scheme in finite time would effectively result in zero valuable code being successfully squatted.

I always wonder why people bother with providing source under a source available license. It makes outside contributions a lot less likely. Your active community of people working on the code base effectively becomes your employees. There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing. Including free usage and distribution of the work they did. It's not likely to be helpful. My attitude to source available products is the same as to proprietary products. I tend to limit my dependency on those. Companies have short life spans. Many OSS projects I use have a history of surviving the implosion of companies that once actively contributed to them. Developer communities are much more resilient than companies. Source unavailable effectively becomes source unavailable when companies fail. Especially VC funded companies are kind of engineered (by VCs) to fail fast. So, it's just not a great basis for making a long term commitment. If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license. Somebody could take over the project or fork it or even create a new company around it. Some of the original developers would probably show up. A project like that is resilient against that. And projects like that have active contributors outside of the corporate context that provide lots of contributions. Because of the license. You don't get that without a good OSS license. I judge software projects by the quality of their development communities. It needs to have diversity, a good mix of people that know what they are doing, and a broad enough user community that the project is likely to be supported in perpetuity. Shared source provides only the illusion of that. Depending on them is risky. And that risk is rarely offset by quality. Of course people use proprietary software for some things. And that's fine. I'm no different. But most of the stuff I care about is OSS.

Counterpoint: I’ve often wished the proprietary software I use was source-available so that I could fix bugs for myself. The idea of doing free work for a company does feel weird. But when some bug is really getting on my nerves, being able to fix it and not have to deal with it anymore is a huge benefit!

Maybe that's the whole point. Entities which rely on the product enough to propose contributions are more likely to be paying customers who really need to have a given feature available? People seem to complain that they are burnt out by open source quite often so not sure that there are that many contributions apart from a couple projects. It may also protect a project against business vultures. If you are trying to monetize your project but someone richer than you forks it and offer it for free, what can you do? Yet, by being source available, the code is still auditable. It is easier for people to understand how the software works. And nowadays you can fine tune an LLM over it I guess... Seems that is might also be a valid perspective? You can probably have a kind of bus clause so that source code does not become abandoned?

In the case of Fizzy, the app that 37signals has made “source available”, the real motivation for publishing is form of advertising for Ruby on Rails. DHH is on a mission to show that you can write great software with way less bullshit than is in vogue. This code base is sparkling in its design. No build frontend, server side rendered templates, minimal js used primarily to drive interactivity, extremely simple models, jobs, and controllers. It has < 3000 lines of js with incredibly rich interaction design, when was the last time you saw that?

>minimal js used primarily to drive interactivity Damn weirdos. Next you're going to tell me that you can deploy it without k8s or even a container?! /s

Iirc the issue with SSPL was that releasing the entire stack under SSPL would basically be impossible, since you wouldn't have the rights to release, for example, the Linux kernel, under it.

Yes. I also read it somewhere that, for example, if you hosted your service on Microsoft IIS, SSPL required you to publish IIS source, regardless of the fact that you don't have it.

Are you suggesting that they should've bribed OSI, or.. ?

/s would be nice. But just in case, I was suggesting to work closely with OSI and do enough back and forth until a license is agreed upon.

Well technically Redis had a fork before it became source available known as valkey which is still in bsd license Terraform was forked to create opentofu if I remember correctly I think the most recent example is kind of minio for this type of thing no? Also I am interested what are some open source projects which became closed source since it seems that you haven't named any and I am curious how they can do that. There must be some legal laws protecting it.

If a project switches from an open-source to a closed-source license, then from the outside, it just looks like the project was abandoned. The final commit that was published under the open-source license will always be open source. It's the future commits that are now closed source. So no, I don't have any specific examples of that happening. In the case of both Redis and Terraform, the forks were announced after the license change, not before. Indeed, the forks were motivated by the license change. The community didn't get a warning "hey, we're about to change the license, fork it while you still can!". It just changed. That's what I mean when I say the license change does not apply retroactively. The commit of Terraform that existed before the license change is still open-source. I could create a fork branching off that commit today if I wanted to.

> Personally I think differentiation between "open source" and "source available" is good Maybe, but I think that "source available" isn't detailed enough and can mean many many different things. > Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc). Point in case. For me there is one group, under something like BSL or FSL or SSPL which mostly restricts you from competing with the project's creators (e.g. making your own SaaS out of it), but everything else is fair use, you can use it in prod to make money at any size, etc. And a separate, more restrictive one, which has size, or production restrictions (you can't run the software if you're a commercial entity). Source available sounds like a good description for the second one, because it's just available, little more. But for the first one where you can do whatever you want with one single exception that doesn't impact 99.9999% of potential users, it's not a good and clear enough description.

I agree with you the "source available" is overstretched. It's hard to come up with a good new label for the first group. Maybe "Open Use" or "Fair Source".

Rust in the kernel is no longer experimental (lwn.net)

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no going back to a C only Linux.

Does this mean that all architectures that Linux supports but Rust doesn't are straight in the bin?

[dead]

That's not how it works. Once in control, vanguardism defends itself by suppressing all dissent. It does not dissipate. It grows like a virus.

Maybe so. But on the other hand as the community grows and becomes politically diverse, you will stop being afraid of being branded part of political movements that you don’t like just by using a certain programming language, which is… good enough?

What yucky politics?

Insane people have decided that Rust is on the "woke" side of the culture war. Reading the phoronix comment section is hilarious because any post about rust devolves into a bunch of boomers whining about "blue-haired woke rust programmers" and other nonsense.

Probably something silly because we live in the age of polarization and thoughts compressed in 150 character tweets.

Agreed, the vagueposting is indication of ill-intent of the top-level comment. No hyperlinks or specifics, it might as well be a game of mad-libs where you insert your grievance here.

I am not fluent in rust. I even never wrote a single rust statement. I fear this step will divide the kernel developer family on a fundamental level. I think this is no good thing to have in Linux. After Microsoft go full haywire on win 11 Linux was a well regarded alternative. I fear the rust situation (and the drama from the rust developers) will drive users away. Just my 2 cents

If drama was going to drive Linux kernel developers away, it would have just been Torvalds working on it alone for 30 years. For better or worse, that community has selected for having very thorough antibodies to conflict.

1. Which drama? 2. End users absolutely do not care in which programming language an application (or OS, they can't tell the difference and don't care) is written in. They only care if it does the job they need quickly, safely and easily.

I'm guessing he means Rust voicing solidarity with Ukraine and sympathy with everyone affected by a conflict? It's hard to tell when people vaguepost. I guess wars of invasion/annexation are too controversial to oppose. "Before going into the details of the new Rust release, we'd like to state that we stand in solidarity with the people of Ukraine and express our support for all people affected by this conflict."

I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write. Mostly Rust has been used for drivers so far. Here's the first Rust driver I found: https://github.com/torvalds/linux/blob/2137cb863b8018710315138f40eefcceb8584d1b/drivers/pwm/pwm_th1520.rs It has one trivial use of `unsafe` - to support Send & Sync for a type - and that is apparently temporary. Everything else uses safe APIs.

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

After all the resistance to Rust in the Linux Kernel, it's finally official. Kudos to the Linux Rust team!

wasn't there like a drive by maintainer rejection of something rust related that kind of disrupted the asahi project ? i can't say i followed the developments much but i do recall it being some of that classic linux kernel on broadway theater. i also wonder if that was a first domino falling of sorts for asahi, i legitimately can't tell if that project lives on anymore

IIRC, it was not about Rust vs. C, but a commotion rooted from patch quality and not pushing people around about things. Linux Kernel team has this habit of a forceful pushback which breaks souls and hearts when prodded too much. Looks like Hector has deleted his Mastodon account, so I can't look back what he said exactly. Oh, I still have the relevant tab open. It's about code quality: https://news.ycombinator.com/item?id=43043312

Microkernel architecture doesn't magically eliminate bugs, it just replaces a subset of kernel panics with app crashes. Bugs will be there, they will keep impacting users, they will need to be fixed. Rust would still help to eliminate those bugs.

I agree it doesn’t magically eliminate bugs, and I don’t think rearchitecting the existing Linux kernel would be a fruitful direction regardless. That said, OS services split out into apps with more limited access can still provide a meaningful security barrier in the event of a crash. As it stands, a full kernel-space RCE is game over for a Linux system.

Just use MINIX, or GNU Hurd.

Even better, be like the Amish, and build your own as much as you can.

> same Mike in an org wide email: thank you all for your support. Starting next week I will no longer be a developer here. I thank my manager blah blah... I will be starting my dream role as Architect and I hope to achieve success. > Mike's colleagues: Aww.. We'll miss you. > Mike's manager: Is this your one week's notice? Did you take up an architect job elsewhere immediately after I promoted you to architect ?!

Joke, enterprise edition..

C++ devs are spinning in their graves now.

Why should they? Other platforms don't have a leader that hates C++, and then accepts a language that is also quite complex, even has two macro systems of Lisp like wizardy, see Serde. OSes have been being written with C++ on the kernel, since the late 1990's, and AI is being powered by hardware (CUDA) that was designed specifically to accomodate C++ memory model. Also Rust compiler depends on a compiler framework written in C++, without it there is no Rust compiler, and apparently they are in no hurry to bootstrap it.

The C++ that have the humility to realize are using Rust.

Nah, they just smile when they see LLVM and GCC on Rust build output.

Yes it does, alongside C++, Rust isn't available everywhere. There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon. POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,... Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded. Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence. Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.

I agree with you for the most part, but it's worth noting that those standards can expose a C API/ABI while being primarily implemented in and/or used by non-C languages. I think we're a long way away from that, but there's no inherent reason why C would be a going concern for these in the Glorious RIIR Future:tm:.

You have made two major mistakes, which is common among Rust proponents, and which is disconcerting, because some of those mistakes can help lead to memory safety bugs in real life Rust programs. And thus, ironically, by Rust proponents spreading and propagating those mistakes and misconceptions about Rust, Rust developers mislearn aspects, that then in turn make Rust less safe and secure than it otherwise would have been. 1: The portions of the code that have to be checked of unsafe blocks are not limited to just those blocks. In fact, in some cases, the whole module that tiny unsafe blocks resides in have to be checked. The Rustonomicon makes this clear. Did you read and understand the Rustonomicon? 2: Unsafe Rust is significantly harder than C and C++. This is extra unfortunate for the cases where Rust is used for the more difficult code, like some performance-oriented code, compounding the difficulty of the code. Unsafe Rust is sometimes used for the sake of performance as well. Large parts of the Rust community and several blog posts agree with this. Rust proponents, conversely, often try to argue the opposite, thus lulling Rust developers into believing that unsafe Rust is fine, and thus ironically making unsafe Rust less safe and secure. Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively undermining safety and security. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages.

1. This doesn't really matter for the argument. Most of the time you can audit unsafe blocks, in some instances the invariants you are upholding require you to consider more code. The benefit is still that you can design safe interfaces around these smaller bits of audited code. 2. I agree it's harder, I feel like most of the community knows and recognises this. > Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively *undermining safety and security*. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages. I don't think there is any evidence that Rust is undermining safety and security. In fact all evidence shows it's massively improving these metrics wherever Rust replaces C and C++ code. If you have evidence to the contrary let's see it.

> I prefer debugging C I prefer not having to debug... I think most people would agree with that.

I prefer a billion dallars tax free, but here we are:(

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

Also, Swift Embedded came out of the effort to eventually use Swift instead for such use cases at Apple.

Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development. [0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.

What matters is what Apple thinks, and officially it is, to the point it is explicitly written on the documentation.

So you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.

No, they are not saying that at all??

> Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it. Google is transitioning large parts of Android to Rust and there is now first-party code in Chromium and V8 in Rust. I’m sure they’ll continue to write new C++ code for a good while, but they’ve made substantial investments to enable using Rust in these projects going forward. Also, if you’re imagining the board of a multi-trillion dollar market cap company is making direct decisions about what languages get used, you may want to check what else in this list you are imagining.

Unless rules have changed Rust is only allowed a minor role in Chrome. > Based on our research, we landed on two outcomes for Chromium. > We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++. > We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation. -- https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html Also even though Rust would be a safer alternative to using C and C++ on the Android NDK, that isn't part of the roadmap, nor the Android team provides any support to those that go down that route. They only see Rust for Android internals, not app developers If anything, they seem more likely to eventually support Kotlin Native for such cases than Rust.

> Obviously not Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.

Game development, graphics and VFX industry, AI tooling infrastructure, embedded development, Maker tools like Arduino and ESP32, compiler development.

Whenever the public has heard about the language it's always been Python.

With lots of CUDA C++ libraries, among others.

I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.

Sure there are plenty of them, hence why you seem remarks like wanting to use Rust but with a GC, or assigned to Rust features that most ML derived languages have.

Steve Klabnik? Either way, that survey (you could have linked to it) has some issues. https://survey.stackoverflow.co/2025/technology#most-popular-technologies-language Select the "Learning to Code" tab. > Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.) It describes two check marks, yet only has a single statistic for each language. Did StackOverflow mess up the question or data? The data also looks suspicious. Is it really the case that 44.6% of developers learning to code have worked with or want to work with C++?

[delayed]

Also you can't do self-referential strutcs. Double-linked lists are also pain to implement, and they're are heavily used in kernel.

> Also you can't do self-referential strutcs. You mean in safe rust? You can definitely do self-referential structs with unsafe and Pin to make a safe API. Heck every future generated by the compiler relies on this.

Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.

If you're developing, you generally have control over the development environment (+/-) and you can install things. Plus that already reduces the audience: set of people with oddball hardware (as someone here put it) intersected with the set of people with locked down development environments. Let alone the fact that conceptually people with locked down environments are precisely those would really want the extra safety offered by Rust. I know that real life is messy but if we don't keep pressing, nothing improves.

Using LLVM somewhere in the build doesn't require that you compile everything with LLVM. It generates object files, just like GCC, and you can link together object files compiled with each compiler, as long as they don't use compiler-specific runtime libraries (like the C++ standard library, or a polyfill compiler-rt library). `clang-cl` does this with `cl.exe` on Windows.

> There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash Java, really? I don’t think Java has been essential for a long time. Is Perl still critical?

critical at build time, not runtime

From my experience of building LFS it appears to be needed to build part of the tool chain. https://linuxfromscratch.org/lfs/view/development/chapter07/perl.html

A system only needs one programming language to be useful, and when there's only one it's basically always C.

Everyone forgets forth.

The “Ouch.” was in reference to being compared to Phoronix. Has anyone found them to be inaccurate, or fluffy to the point it degraded the content? I haven’t - but then again, probably predominantly reading the best posts being shared on aggregators.

I don't know about the "ouch" but the rest of the comment seems pretty clear that they didn't intend to imply the clickbait.

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

If you’re trying to demonstrate something about Rust by pointing out that someone chose C over Perl, I have to wonder how much you know about the positive characteristics of C. Let alone Rust.