I believe Google has developed a Rust implementation of the binder driver which was recently merged, and they are apparently planning to remove the original C implementation. Considering binder is essential for Android that would be a major step too.

I can confirm that the ChromeOS debian container now has defaulted to turn off GPU acceleration, perhaps to turn on other acceleration on this Mali.

[flagged]

I'm sorry, what?

If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase.

Rust isn’t an invading tribe. It’s just a tool.

They wrote their own language (C) too. They invented a new language because the current crop of languages didn't suit their needs. Your argument ignores the parts of history that are inconvenient and highlights the ones that you think support it.

"invading"

I'm sure your choice of words helps the discussion.

Back when the primary consumers of the kernel were other researchers. Not billions of machines running our society.

the kernel is the value part, not the language that the kernel is written in

That’s a reasonable position today, but what about in 20 years?

> Rustians disparage C

No, the 50+ years of ridiculously unavoidable memory corruption errors have done more to disparage C than anyone working in another language.

Thank you for asking this. It was presented matter of fact and I would not have appreciated that it was something less than settled. The best I can find from googling was rumors and speculation (insert comment in reply with more rumors and speculation). I also don't necessarily think it means someone is a Bad Guy if true. I want people to be able to have anonymous alter egos online if that's what they want and they're not doing any harm.

Isn't Asahi Lina Married to some other japanese Vtubber now? I mean maybe you'd fake all that but I doubt it. Both are more likely real people who are different. The people have totally different eccentricties its really hard to fake that type difference for a long time.

[source] https://x.com/Lina_Hoshino/status/1862840998897861007

Yes. This forum has collated the evidence that Asahi Lina is the VTuber alter ego of Hector Martin:

https://archive.today/dcc3I#-asahi-lina

There is. You can easily find by googling "hector martin" "asahi lina" and you will soon find a pile of obsessively archived evidence.

My view, now that Hector has resigned from the LKML both as himself and as Lina, is there is no problem any more. If Hector wants to project a persona, or decide his identity is the persona, or maybe multiple personas, that is fine on social media. People do that. So long as he's not sockpuppeting Linux kernel maintenance, it's fine.

At this point I suspect anyone who even asks that question of concern trolling. The evidence is overwhelming.

oh no not again.

yes, like 99.(9)%

Yes, that's the entry of the rabbit hole, and reader is advised to dig their own tunnel.

I remember following the tension for a bit. Yes, there are other subjects about how things are done, but after reading it, I remember framing "code quality" as the base issue.

In high-stakes software development environments, egos run high generally, and when people clash and doesn't back up, sparks happen. If this warning is ignored, then something has to give.

If I'm mistaken, I can enjoy a good explanation and be gladly stand corrected.

This is what happened here. This is probably the second or third time I witness this over 20+ years. Most famous one was over CPU schedulers, namely BFS, again IIRC.

Thanks! Let me edit this in, too.

Edit: Nah, I can't, too late.

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements.

---

Yes. I remember that message.

Also let's not forget what marcan said [0] [1].

In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing out to them to GTFO of "his" lawn (which I understand again, not condone. I'd have acted differently).

This again boils down to code quality matters. Rust is a small child when compared to the whole codebase, and weariness from old timers is normal. We can discuss behaviors till the eternity, but humans are humans. You can't just standardize everything.

Coming to marcan, how he behaved is a big no in my book, too. Because it's not healthy. Yes, the LKML is not healthy, but this is one of the things which makes you wrong even when you're right.

I'm also following a similar discussion list, which has a similar level of friction in some matters, and the correct thing is to taking some time off and touching grass when feeling tired and being close to burnout. Not running like a lit torch between flammable people.

One needs to try to be the better example esp. when the environment is not in an ideal shape. It's the hardest thing to do, but it's the most correct path at the same time.

[0]: https://web.archive.org/web/20250205004552mp_/https://lwn.ne...

[1]: https://lkml.org/lkml/2025/2/6/404

They have less and less resources

That was way way blown out of proportion. https://lwn.net/Articles/991062/ has a much less somber quote from just three months later:

> Ted Ts'o said that the Rust developers have been trying to avoid scaring kernel maintainers, and have been saying that "all you need is to learn a little Rust". But a little Rust is not enough to understand filesystem abstractions, which have to deal with that subsystem's complex locking rules. There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn

Ted was being an asshole, nobody was asking him to learn Rust, he completely misinterpreted the point being made and then proceeded to go on an angry rant for like 5 minutes in the middle of a presentation which just is kind of disrespectful.

Yes that was it indeed thanx for finding it. I kept coming to this video but couldn't find the time index.

Linus Torvalds greenlit Rust in the kernel, and as a BDFL, he is the one to decide. He has no reason to be upset with any decision because ultimately, all decisions are his own.

If he didn't want Rust in the kernel, he would have said it, and there would have been no Rust in the kernel. It is also the reason why there is no C++ in the kernel, Linus doesn't like C++. It is that simple.

And I respect that, Linux is hugely successful under Linus direction, so I trust his decisions, whatever opinion I have about them.

I can't find the movie, but there was a guy angry that stated that he should not have to learn Rust, nobody should. And Rust should not be in the kernel.

It might be if the original answer wasn't that ignorant of the question's origin.

I guess in practice you'd want to have Rust installed as part of your local build and test environment. But I don't think you have to learn Rust any more (or any less) than you have to learn Perl or how the config script works.

As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.

Learn rust to a level where all cross language implications are understood, which includes all `unsafe` behaviour (...because you're interfacing with C).

Yes it does.

Depends on the change being made.

If they completely replace an API then sure, probably.

But for most changes, like adding a param to a function or a struct, they basically have to learn nothing.

Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion.

That's exactly the original question.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

I'm using it for frontend web development and it's perfect. Much better than Go or Java would be. It's pretty wild that the language I use in the browser is also in the kernel.

Is this the same NIOS that runs on FPGA? We wrote some code for it during digital design in university, and even an a.out was terribly slow, can't imagine running a full kernel. Though that could have been the fault of the hardware or IP we were using.

You fell into the trap I predicted a few years ago when the renaming happened. Microblaze refers to the old microblaze soft core, not the new one that they named the same thing and that is based on RISCV.

There was a time when it came to 64 bit support Alpha really was the only game in town where you could buy a server without adding a sixth zero to the bill. It was AMD, not Itanium that killed Alpha.

They probably get a few for "free" from LLVM supporting them

Itanium was mainly dropped because it was impeding work in the EFI subsystem. EFI was originally developed for Itanium before being ported to other platforms, so the EFI maintainers had to build and test their changes to shared code on Itanium. They eventually decided that this wasn't worth the effort when there was basically nobody running modern Linux on Itanium besides a few hobbyists. I imagine that alpha and hppa will get dropped in the future if they ever also create an undue maintenance burden. There's more context here if you're interested: https://lwn.net/Articles/950466/

I do wonder how many humans beings are running the latest linux kernel on Alpha.

how on earth is linux being compiled for platforms without a GCC?

additionally, I believe the GCC backend is incomplete. the `core` library is able to compile, but rust's `std` cannot be.

https://rust-for-linux.com/ shows a list.

The amount of unsafe is pretty small and limited to where the interfacing with io or relevant stuff is actually happening. For example (random selection) https://lkml.org/lkml/2023/3/7/764 has a few unsafes, but either: a) trivial structure access, or b) documented regarding why it's valid. The rest of the code still benefits.

But that's not the only reason Rust is useful - see the end of the write-up from the module author https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ ("Rust is magical!" section)

I’ve done a decent amount of low level code - (never written a driver but I’m still young). The vast majority of it can be safe, and call into unsafe wrapped when needed. My experience is that a very very small amount of stuff actually needs unsafe and the only reason the unsafe C code is used is because it’s possible not because it’s necessary.

Unsafe in Rust doesn't mean anything goes. Specifically it means that you are going to 1) dereference a raw pointer; or 2) call an unsafe function/method; or 3) access/modify a mutable static variable; or 4) implement an unsafe trait; or 5) access fields of a union.

You still get the safety guarantees of Rust in unsafe code like bounds checking and lifetimes.

Why does that matter? Rust with some "unsafe" is still much nicer to use than C.

In fact one of the main points of Rust is the ability to build safe abstractions on top of unsafe code, rather than every line in the entire program always being unsafe and possibly invoking UB.

The point is that lots of the code won't be `unsafe`, and therefore you benefit from memory safety in those parts.

[flagged]

> Functions like that can and should be marked unsafe in rust.

That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.

So if you're writing a device driver in rust...

- Hardware access is unsafe - Kernel interface is unsafe

How much remains in the layer in-between that's actually safe?

Sure, but those are non-central to what the program is doing. Writing to the wrong register offset and hosing main memory is a thing that happens when developing drivers (though usually it breaks obviously during testing).

I'm not a rust or systems programmer but I think it meant that as an ABI or foreign function interface bitfields are not stable or not intuitive to use, as they can't be declared granularily enough.

Across binary libraries ABI, regardless of static or dynamically linked?

> ...not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every platform. ... there remains concern among several of the maintainers about breaking that guarantee, despite the fact that people on the only target that would be affected basically saying they'd rather see that guarantee broken.

The proper approach to resolving this in an elegant way is to make the guarantee target-dependent. Require all depended-upon crates to acknowledge that usize might differ from uptr in order to unlock building for "exotic" architectures, much like how no-std works today. That way "nearly every platform" can still rely on the guarantee with no rise in complexity.

I brought up Go because it was designed around the same time and, while it gets a lot of flack for some of its other design decisions, this particular one seems prescient. However, I would be remiss if I gave the impression that the reasoning behind the decision was anticipation of some yet unseen future; the reality was that int and uint (which are not aliases for sized intN or uintN) were not initially the same as ptrdiff_t and size_t (respectively) on all platforms. Early versions of Go for 64-bit systems had 32-bit int and uint, so naturally uintptr had to be different (and it's also not an alias). It was only later that int and uint became machine-word-sized on all platforms and so made uintptr seem a bit redundant. However, this distinction is fortuitous for CHERI etc. support. Still, Go on CHERI with 128-bit uintptr might break some code, however such code is likely in violation of the unsafe pointer rules anyway: https://pkg.go.dev/unsafe#Pointer

Yet Rust is not Go and this solution is probably not the right one for Rust. As laid out in a link on a sibling comment, one possibility is to do away with pointer <=> integer conversions entirely, and use methods on pointers to access and mutate their addresses (which may be the only thing they represent on some platforms, but is just a part of their representation on others). The broader issue is really about evolving the language and ecosystem away from the mentality that "pointers are just integers with fancy sigil names".

I'd say, that even more than pointer sizes, the idea that a pointer is just a number really needs to die, and is in no way a forward looking decision expected of a modern language.

Pointers should at no point be converted into numbers and back as that trips up many assumptions (special runtimes, static/dynamic analysis tools, compiler optimizations).

Additionally, I would make it a priority that writing FFIs should be as easy as possible, and requires as little human deliberation as possible. Even if Rust is safe, its safety can only be assumed as long as the underlying external code upholds the invariants.

Which is a huge risk factor for Rust, especially in today's context of the Linux kernel. If I have an object created/handled by external native code, how do I make sure that it respects Rust's lifetime/aliasing rules?

What's the exact list of rules my C code must conform to?

Are there any static analysis/fuzzing tools that can verify that my code is indeed compliant?

Great info!

Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer <=> integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance.

I think the answer to "can this be solved with editions" is more "kinda" rather than "no"; you can make hard breaks with a new edition, but since the old editions must still be supported and interoperable, the best you can do with those is issue warnings. Those warnings can then be upgraded to errors on a per-project basis with compiler flags and/or Cargo.toml options.

I guess today, instead of 128bit pointers we have 64bit pointers and secret provenance data inside the cpu, at least on the most recent shipped iPhones and Macs.

In the end, I’m not sure that’s better, or maybe we should have had extra large pointers again (in that way back 32bit was so large we stuffed other stuff in there) like CHERI proposes (though I think it still has secret sidecar of data about the pointers).

Would love to Apple get closer to Cheri. They could make a big change as they are vertically integrated, though I think their Apple Silicon for Mac moment would have been the time.

I wonder what big pointers does to performance.

Don’t spread FUD, you can check some example code yourself.

https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...

A C compiler is also relatively easy to implement (compared to a Rust compiler) if you're making your own hobby OS with its own C compiler and libc.

From my experience of building LFS it appears to be needed to built as part of the tool chain.

https://linuxfromscratch.org/lfs/view/development/chapter07/...

It's extremely hard to build any unixly userspace without perl dependencies.

critical at build time, not runtime

I am yet to find one without it, unless you include Windows, consoles, or table/phone OSes, embedded RTOS, which aren't anyway proper UNIX derivatives.

I would be. Mostly because while Zig is better than C, it doesn't really provide all that much benefit, if you already have Rust.

IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel.

Rust is different because it both:

- significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities.

- And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld.

That doesn't mean Zig is a bad language for a particular project, just that it's not worth adding to an already massive project like the Linux kernel. (Especially a project that already have two languages, C and now Rust).

There’s also I believe an effort to target C as the mid level although I don’t know the state / how well it’ll work in an embedded space anyway where performance really matters and these compilers have super old optimizers that haven’t been updated in 3 decades.

Those don’t really support C in any real stretch, talking about general experience with microcontrollers and closed vendor toolchains; it’s a frozen dialect of C from decades ago which isn’t what people think of when they say C (usually people mean at least the 26 year old C99 standard but these often at best support C89 or even come with their own limitations)

Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...

I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.

GNU/Linux isn't the only system out there, POSIX last update was in 2024 (when C requirement got upgraded to C17), and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure.

Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.

It's been mentioned obliquely, but what's considered "part of the compilation process" is different between Rust and C.

Most of the examples of "this is what makes Rust compilation slow" are code generation related; for example, a Rust proc_macro making compilation slow would be equivalent to C building a code generator (for schemas? IDLs?), running it, then compiling the output along with its user.

Runtime memory issues probably have a significantly higher total cost.

But of course that doesn't negate this cost, but building can always be done on another machine as a way to circumvent the problem.

Rust compilation is also almost instant, if you have a relatively small project.

It's only when you get very large projects that compilation time becomes a problem.

If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]?

[1]: https://github.com/microsoft/typescript-go

Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.

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.

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.

If only Rust had a spec to do that with

> it always has been and always will be available everywhere

"Always has been" is pushing it. Half of C's history is written with outdated, proprietary compilers that died alongside their architecture. It's easy to take modern tech like LLVM for granted.

> C will continue to be used because it always has been and always will be available everywhere

Yes, you can use it everywhere. Is that what you consider a success?

> You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM.

This is exactly what I'm saying. Do you think HW drives SW or the other way around? When Rust is in the Linux kernel, my guess is it will be very hard to find new HW worth using, which doesn't have some Rust support.

How many of them are running Linux, and how many of them are running a modern kernel?

Rust wants all memory to be modeled as an ownership tree: the same bit of memory can't be owned by more than one data structure. A doubly linked list breaks that requirement so it can't be modeled in safe Rust directly. The options are using unsafe, or using one of the pointer wrapper types that have runtime checks that ensure correct behavior and own the underlying memory as far Rust is concerned.

The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface.

If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way.

That is how all standard library collections in Rust works. They’ve just gone to the length of formally verifying parts of the code to ensure performance and safety.

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

> experienced people often are more hesitant to learn new things

I believe the opposite. There's some kind of weird mentality in beginner/wannabe programmers (and HR, but that's unrelated) that when you pick language X then you're an X programmer for life.

Experienced people know that if you need a new language or library, you pick up a new language or library. Once you've learned a few, most of them aren't going to be very different and programming is programming. Of course it will look like work and maybe "experienced" people will be more work averse and less enthusiastic than "inexperienced" (meaning younger) people.

I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.

According to the strange data at https://survey.stackoverflow.co/2025/technology#most-popular... , 44.6% have responded positively to that question regarding C++. But there may be some issues, for the question involves two check boxes, yet there is only one statistic.

There's a "point of no return" when you start to struggle to hire anyone on your teams because no one knows the language and no one is willing to learn. But C++ is very far from it.

Zig at least claims some level of memory safety in their marketing. How real that is I don't know.

Llama.cpp is called Llama.cpp, so there’s that…

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

In Rust dev, I haven't needed Valgrind or gdb in years, except some projects integrating C libraries.

Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.

If it wasn't clear, I have to debug Rust code waaaay less than C, for two reasons:

1. Memory safety - these can be some of the worst bugs to debug in C because they often break sane invariants that you use for debugging. Often they break the debugger entirely! A classic example is forgetting to return a value from a non-void function. That can trash your stack and end up causing all sorts of impossible behaviours in totally different parts of the code. Not fun to debug!

2. Stronger type system - you get an "if it compiles it works" kind of experience (as in Haskell). Obviously that isn't always the case, but I can sometimes write several hundred lines of Rust and once it's compiling it works first time. I've had to suppress my natural "oh I must have forgotten to save everything or maybe incremental builds are broken or something" instinct when this happens.

Net result is that I spend at least 10x less time in a debugger with Rust than I do with C.

https://blog.cloudflare.com/incident-report-on-memory-leak-c...

better to crash than leak https keys to the internet

The panic_immediate_abort feature should prevent this. build-std is the name of the feature that recompiles the Rust standard libraries with your chosen profile, so the combination of these two features should result in no unwinding code bloat.

Okay. That sounds like a reasonable explanation. Thanks!

I’d like to take a swipe at this

Rust has no_std to handle not having an allocator.

Tons of things end up being marked “unsafe” in systems/embedded Rust. The idea is you sandbox the unsafeness. Libraries like zero copy are a good example of “containing” unsafe memory accesses in a way that still gets you as much memory safety as possible given the realities of embedded.

Tl;dr you don’t get as much safety as higher level code but you still get more than C. Or maybe put a different way you are forced to think about the points that are inherently unsafe and call them out explicitly (which is great when you think about how to test the thing)

Here is my take on your question.

> I'm curious why your perspective on Rust as a HW engineer.

C, C++ and Rust requires you to know at least the basics of the C memory model. Register variables, heap, stack, stack frame, frame invalidation, allocators and allocation, heap pointer invalidation, etc. There are obviously more complicated stuff (which I think you already know, seeing that you're an embedded developer), but this much is necessary to avoid common memory errors like memory leaks (not a safety error), use-after-free, double-free, data-race, etc. This is needed for even non-system programs and applications, due to lack of runtime memory management (GC or RC). You can get by, by following certain rules of thumb in C and C++. But to be able to write flawless code, you have to know those hardware concepts. This is where knowledge of process and memory architecture comes in handy. You start with the fundamental rule before programming, instead of the other way around that people normally take. Even in Rust, the complicated borrow checker rules start to make sense once you realize how they help you overcome the mistakes you can make with the hardware.

> Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists.

> This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.

I do have an answer, but I don't think it can be explained in a better way than how @QuiEgo did it: You can 'sandbox' those unsafe parts within Rust unsafe blocks. As I have explained elsewhere, these sandboxed parts are surprisingly small even in kernel or embedded code (please see the Rust standard library for examples). As long as you enforce the basic correctness conditions (the invariants) inside the unsafe blocks, the rest of the code is guaranteed to be safe. And even if you do make a mistake there (i.e memory safety), they are easier to find because there's very little code there to check. Rust does bring something new to the table for the hardware.

NOTE: I believe that those parts in the kernel are still in C. Rust is just a thin wrapper over it for writing drivers. That's a reasonable way forward.

> Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.

That isn't true. @QuiEgo already mentioned no_std. It's meant for this purpose. Here is the reference: https://docs.rust-embedded.org/book/intro/no-std.html#bare-m...

No, they are not saying that at all??

No

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

There's an allocation-free subset.

https://www.swift.org/get-started/embedded/

Rust's approach is overkill, I think. A lot of reference counting and stuff is just fine in a kernel.

Nothing wrong with using reference counting for OS development.

Apple is extending Swift specifically for kernel development.

That's not really the case. Not all C APIs are inherently unsafe by construction, and I've always appreciated when someone has wrapped a C library and produced two crates:

- a pure binding crate, which exposes the C lib libraries API, and

- a wrapper library that performs some basic improvements

Stuff in the second category typically includes adding Drop impls to resources that need to be released, translating "accepts pointer + len" into "accepts slices" (or vice versa on return), and "check return value of C call and turn it into a Result, possibly with a stringified error".

All of those are also good examples of local reasoning about unsafety. If a C API returns a buffer + size, it's unsafe to turn it into a reference/slice. But if you check the function succeeded, you unsafely make the slice/reference, and return it from a safe function. If it crashes, you've either not upheld the C calls preconditions (your fault, check how to call the C function), or the C code has a bug (not your fault, the bug is elsewhere).

If you create wrappers that provide additional type information, you do get extra safety and nicer interfaces to work with.

You have extra safety in new code.

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.

> Unless rules have changed Rust is only allowed a minor role in Chrome.

I believe the Chromium policy has changed, though I may be misinterpreting: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

The V8 developers seem more excited to use it going forward, and I’m interested to see how it turns out. A big open question about the Rust safety model for me is how useful it is for reducing the kind of bugs you see in a SOTA JIT runtime.

> They only see Rust for Android internals, not app developers

I’m sure, if only because ~nobody actually wants to write Android apps in Rust. Which I think is a rational choice for the vast majority of apps - Android NDK was already an ugly duckling, and a Rust version would be taken even less seriously by the platform.

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.

Nah I used to read Phoronix and the articles are a bit clickbaity sometimes but mostly it's fine. The real issue is the reader comments. They're absolute trash.

Yeah, I don't know what the hell they are talking about.

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.

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by the way.

https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

By the 90s/early 2000s C/C++ were the only widely used languages that met my criteria. Rust is the first "modern" language to meet that criteria while simultaneously offering memory safety.

If you could afford garbage collection you had plenty of options.

Newer web servers have already moved away from C/C++.

Web browsers have been written in restricted subsets of C/C++ with significant additional tooling for decades at this point, and are already beginning to move to Rust.

Sure, my point is the safety is not why they originally supplanted C and C++. It was seen largely as a tradeoff between ease of development and runtime performance. Memory safety as a goal of its own didn’t become prominent until much later.

I've never met anything written in JS/Typescript that I would call "well written".

The code is written in an embedded style, i.e. no dynamic memory allocation or thread creation/deletion after program initialization. It's also prioritizing reducing memory usage over performance since we are targeting memory constrained devices (and our performance target is 10 tps and we have like 100k tps). Thus we'd use trait objects over monomorphization. Dynamic collections are also off the table unless backed by a fixed-size arena on the stack or static mem.

We heavily use arenas. We also have runtime-typed objects used to represent dynamically typed data like that obtained from JSON/Yaml or over IPC. If we were to be more friendly to modeling in Rust, we'd likely require that all memory reachable from an object node be in the same arena, disallowing common patterns like having list/map's arrays in one arena and having keys/strings in another or in static mem (this allows reusing other buffers without forcing copying all the data, so backing arrays can be smaller).

That works for functions. For datatypes that are used throughout the API, it does not work so well.

rustup is also downloading binary toolchains

No worries I didn't take offenses. I just disagree. The title should've been we reduced bugs in the kernel and here is some proof of that. The 2018-2022-ish hype (I call it bullying campaign) is still strong. Google recently did a blog post about Rust speeding up their development, in the age of LLMs, seriously! I can't stop lol'ing at that

> Stay tuned for details in our Maintainers Summit coverage.

I can argue otherwise. Developer advocacy is a form of marketing (specially for a product traditionally targeted towards tech savvy people)