Posts by Phil Lord

Sudo-rs make me a sandwich, hold the buffer overflows

Re: Another day, another attempt to force this on us

"You should be building offline - so all dependencies are available at build time with controlled sources."

Yes, I agree. That is how it works in Rust.

Re: Another day, another attempt to force this on us

Believe that if you want. I can say for sure I know Rust far better than I know C++.

Installation of dependencies using deb/rpm is platform specific and because it will not be specified in the repo does not support a reproducible build.

Re: Another day, another attempt to force this on us

I don't really care about your example. The point being made is that if you do want to use boost, can you specify this in a standard way, with good tooling to make sure it all happens? In C++, the answer is no. In Rust, the answer is yes.

These are two very different design philosophies. Rust says "have the smallest stdlib you need, then use dependencies and make them usable". C++ says "have a good standard library, then add libraries if you must". Advantages and disadvantages for sure. But to compare Rust stdlib to C++ stdlib and discover that C++ has a bigger one is, as I have noted, not a good argument.

Re: Another day, another attempt to force this on us

All depends on what "vanilla rust" means to you and why you think it is important.

With "vanilla C++" can you depend on the boost libraries, have them downloaded in a clear, specified and reproducible way that you know will compile on someone elses machine? That works with Rust. Does it with work with C++? Or Python?

Re: Another day, another attempt to force this on us

"Let's try to be nuanced - I think you have to accept that part of what people want from C++ includes the stability and that means the standard defines what you can rely on."

Yes, indeed. It is a very similar argument to Python's batteries included philosophy. You can do all the things you want to without dependencies.

I don't know how it is in C++ so much, but the probably is that you can do HTTP in python without dependencies but most people use requests. You named boost yourself; while it does not replicate std library in the way that requests replicates HTTP support, it falls into a similar category. Many C++ developers find boost indispensible.

Rust has taken the other approach. It has said that it will have a small library, and use dependencies. On the other hand, dependencies in rust are a core part of the ecosystem and are well supported in both the language and the tooling. That isn't true in python for instance -- it has had many options over the years, but it only recently got a standard "project specification" file format (which is partly borrowed from Rust); and the tooling is still behind Rusts and not standard (i.e. pipenv, poetry, uv). My experience with C++ is much less, but as IIUC, it still does not have this.

I agree with you, though, as it matures it will need a core set of libraries that you can depend on strong stabilities/future proofing guarantees probably linked to the same ones that Rust itself supports. These will still be delivered by crates, though, I am sure. Rust will access "standard" libraries in the same way that it accesses any other third party dependency.

What does Rust have? Well, you already know that. It has a strong type system which it also uses for lifetime management, meaning that it provides strong safety guarantees. That is the thing that is it's unique sales point.

Personally, I used it because I wanted to do something fast, I have done lots of functionalesque programming. I had a choice: I could learn C++, GO or Rust in enough detail to do this. I choose Rust. In practice, I found it quite nice to code with and it fulfilled its promise of being fast. I see quite a few other people in my area (scientific computing) making the same decision.

I've no desire to port PhotoShop. It's not something I use, nor something I want.

Re: Another day, another attempt to force this on us

"

if you need a third party lib to put four threads into an array and then call join - your language is broken.

The STL and the Rust Stdlib are the equivalents. If it's not in the stdlib, you can't use it as demonstration of how much better life is in your world,

"

I think that I would disagree with this. What you are saying is, essentially, that C++ has a bigger standard library than Rust, therefore it is better. Importing crates is the way that you get additional functionality. It would be like arguing in that, in your example, Python is better than C++ because in Python list manipulation is there by default, while in C++ you have to import vector.

Is Rayon a third party lib? Well, in a sense, yes, although the developers are in that case are part of the Rust core team. There are a set of crates which are very widely used, and well supported. rand, clap, serde, syn and quote and so forth all leap to mind. Arguing that a comparison is only valid if you exclude all of these things is not reasonable.

A much more valid criticism is that the Rust dependency supply chain is not so clear about which crates are well supported and that is needs some "official" ones. It is a known issue and one that the Rust foundation is working on.

Re: Another day, another attempt to force this on us

I think that your conclusion that the Rust stdlib is crap is flawed. The idea of having a small stdlib was an design decision. There were attempting to avoid the problem we have seen in other languages which have "batteries included" standard libraries. That sounds like a good idea, but over time, some of these batteries tend not to be so good, and so the libraries atrophy. Python is the obvious example with Requests and the standard library http support being a good example.

Rust instead provides good mechanisms and tooling for supporting dependencies as first class entities (i.e. crates). Pulling one of them in to run parallelism is not unexpected and not really evidence that stdlib is crap.

You might argue that the Rust approach is flawed, but that is a bigger and more general question.

France offers US scientists a safe haven from Trump's war on woke

Re: les queer studies?

I got through some of it. Not all the words mean what you might think. "Intimacies" meaning patting dogs on head and having them as companions rather than the more literal interpretation. Cyborg is a similar things -- using machines as part of our daily lives rather than replacing parts of ourselves with them.

It's quite heavy going, and I didn't understand all of it. That doesn't mean it wrong, of course.

Strap in, get ready for more Rust drivers in Linux kernel

Re: Such awful interop

When Rust was written syntactic interoperabilty with C wasn't an objective, and it doesn't have it. So the declaration of C function headers in Rust looks like Rust code not C.

However, it is a purely syntactic transformation. It has long since been automated with bindgen. And since it has now been automated, it is possible to do at build time, using a build script. Or, you can do it at compile time with a macro. You can do it manually if you want, but this only makes sense if, for example, you want to bind to only one or two C functions.

It is not different for the sake of it. It is different because it is easier to use the same syntax as Rust in the first instance and then automate it over time. Eventually, they might push bindgen directly into the compiler and have it as a keyword like with zig, but the advantages over what we have now are not that great.

Linux royalty backs adoption of Rust for kernel code, says its rise is inevitable

Re: Load-bearing borrow-checker

If a soundness problem is discovered in a C API, for example, where an API can be easily used in the wrong way, that then opens up an exploitable hole, then I see the same situation. The CVE would be released and any static analysis tool, for example, a C compiler, would be easily able to identify where that exploitable hole was created. I cannot see how, having a correctness tool, like the borrow checker or Rust's type system makes that worse, any than the many C based static analysis checkers that are used on Linux, all of which could themselves be buggy which might in turn allows secondary soundness bugs through.

Of course, if a bug is discovered, there is an issue with disclosure. Once the CVE is created and made public everyone and their dog knows how to exploit the problem because the CVE describes it. That is why there is a process for non public disclosure.

My conclusion: any language compiler and standard (or "core" for R4L) library carries a particular risk because they can potentially allow exploits in an entire ecosystem.

Adding rust to linux clearly increases that surface; it is one of the problems that a multi-language project introduces. Again this, Rust reduces or removes entire classes of security bugs.

I see no reason why you single out the borrow checker for as particularly worrying beyond that.

Re: re: Rust may be modern, but so is Windows 11…

What you are describing is exactly the process that Rust does use for all changes and has used for about the last decade or so. The change is discussed in an RFC with a specification of behaviour. Over time an implementation happens, the Rust documentation is updated, it's moved to nightly, or is made available behind a "feature gate" (that is you have to turn it on by hand if you want it). So testing happens, often internally inside the rust implementation.

And eventually it gets merged to daily and turned on for all usage, waiting for an edition change if it is backward compatible. So, I think all that is happening.

They are building a full formal specification not to change this process which always works, but for those areas such as a safety critical systems, where it is explicitly needed. The formal specification will lag behind which is fine, because in those areas where certification happens, it will mean the implementation is well tested before adoption.

It is not that much different from C, if I understand the C process properly. There is a standard C with a specification. But, in practice, the compilers implement new features first and people start using them well before the release of an updated specification. Again, if I understand correctly, projects like Linux cannot be compiled with a fully standardized C; just like Rust for Linux, actually, which is also using unstable language features.

Re: Load-bearing borrow-checker

The borrow checker and the type system are a key part of Rusts soundness guarantees. But, obviously, bugs can arise and they have done so already. It is considered a problem and once it is discovered, then it gets fixed. Some Rust code that previously compiled may not fail to compile. And where it is possible to do so, Rust normally ships a linter which picks up and fixes the problem automatically in source.

I am not sure what your point is? If rust did not have the borrow checker or a type system, then clearly there could be no soundness bugs in either. How does that make things better?

Re: Veteran C and C++ programmers, however, are understandably worried...

Rust does not forceably bounds check. It allows you to choose which you want. The simpler syntax (`i[n]`) is bounds checked. The non bounds checked version uses a method call and is considered `unsafe`.

Most of the time, however, you just use an iterator. So you just say `for n in i {}`. This does not bounds check as it is provably safe without doing so.

So, Rust is quite explicit about bounds checking, and does not do it where it is not needed. There is very little or no performance compromise here.

Re: re: Rust may be modern, but so is Windows 11…

The big advantage of a formal specification is that it allows you to build multiple competing implementations of the language.

Absolutely critical at one point, because you wanted to avoid vendor lock in. But, if you have a freely available implementation targetting a wide range of platforms, it is less clear the big advantage to me.

I am sure having another pair of eyes go over the current implementation to write down a formal specification will improve things. But, then, most formal specifications are also improved substantially by having one or more implementations.

There are now quite a few languages in very wide use that have no formal specification or have developed one well after having an implementation. I think that the "programming language process" is less doctrinaire in practice than you think.

I don't think many Linux developers have suggested that, though. The main complaint is whether a second language, any second language, is good at all.

Re: The problem is

What things are there that Rust forbids? C/asm? Well, Rust can do that, yes.

And if Rust cannot do something (as indeed, it could not do everything that was needed), it can be expanded. That has happened already.

Re: Things Which Ought be Considered About ANY Add'l Language for Kernel Work

Function calling: Rust can call any C function. It can manipulate any data structure created in C, and can create the same data structures on the Rust side.

It does not have an interpreter. It does have a core and standard library; I think they are only using the core library in Rust for Linux, so it is quite small. LLVM is being used during compilation; but then there is lots of work on using clang to compile which would be the same attack surface. I am unconvinced that LLVM however brings a large attack surface; just a different one from GCC.

Yes, the language is free as in freedom and beer.

The language is not the easiest to learn. It is certainly harder than C because the language is, I think, larger. But then it is more explicit than C with an aim to have fewer corner cases or undefined behaviour. So, arguably, it is easier to use because you have to remember less.

Rust has a good record for backward compatibility. Newer versions of Rust compile old code well; at a binary level, new code can interface and call code compiled with older compilers. It has a written mechanism ("editions") for introducing breaking changes. The only exception is where old code depends on what is considered to be a bug, esp soundness or security bugs.

All of this was considered and was discussed before they put it into the kernel.

Re: Things Which Ought be Considered About ANY Add'l Language for Kernel Work

Is there a standard:

There is a reference implementation with reference documentation. There is a well defined processed for updating the reference implementation. Rust lacks a complete formal specification, although one is being written, for the moment it is targetting an older version.

Is there more than one compiler

In addition to the main reference compiler (rustc) there are three others. One is special purpose (a minimal compiler designed to allow bootstrapping of the tool chain). The other two...well read next answer.

Does the GCC support Rust

There are two compilers that use GCC. One is a codegen backend built on libgccjit (for static rather than Just-in-time compilation). The other is a front end for GCC, which which is aimed to be a complete implementation wrt to compilation but not wrt to soundness of the type system; the latter will be provided by the same system that rustc uses. I *think* the gccjit codegen is usuable, although not complete, while the front-end is actively developed but not usable for anything other than experimentation.

Will future version of Rust invalidate old code.

Rust provides a backward compatibility system (called the "edition system") which means that newer compilers can compile old code; but old compilers may not be able to build new code. The ABI is also stable so libraries can remain on an older edition than their callers (or vice versa). The exception for this is where old code depends on behaviour that is considered buggy especially wrt to soundness. Rust supports a linter system which is capable of applying fixes and is often able to upgrade code written for older editions to newer ones.

In short there are limitations with Rust that may or may not be a problem for certain use cases, but it is overall a fairly reasonable story.

After clash over Rust in Linux, now Asahi lead quits distro, slams Linus' kernel leadership

Re: I'm not agitated, do you do card tricks or is it just the mind reading?

You have asserted lots of things in this thread, particularly about what the motivations of people using Rust are.

For me, I had to choose a few years back between starting a new project in C or in Rust. I wasn't hugely familar with C at the time although, ironically, what is probably the most used thing I have written is in C; and Rust was relatively new, and I didn't know it at all. I picked Rust, and it worked well for me. Nice community, nice tools, expressive language. Steep learning curve, although I *think* that has got easier. The language has certainly advanced a lot since then.

I am glad that you are happy with C and C++.

Re: Rust is snake oil and its proponents are pushy chancers..

Again, that wouldn't insult me. When editors started auto-indenting code, I accepted that they would probably do a better job of it than I would and my code was worse without.

I can understand many reasons why you might not want to use Rust: it's got a steep learning curve, you lack the experience in it, you don't think that it would bring you significant advantage or that the advantages are outweighed by the loss.

I just do not understand why you are so agitated by what other people think is an advantage, nor why you would ascribe such malice to their actions.

I doubt that I am going to understand.

Re: Yet another "rewrite from scratch"

Yes indeed. That is exactly how linux got started.

Re: The role of 'injustice' in software development.

Hard to see what you point is here. Of course "justice" has something to do with software. If you take someone elses code and use it without their permission, you will find yourself on the wrong end of justice. I mean, if I steel the wheels of someones car to use for me own, "this is just engineering and is fundamentally amoral" is not going to get me far.

Re: Rust is snake oil and its proponents are pushy chancers..

You are insulted by someone using a different tool from you?

That I really don't understand.

Okay, it seems that there is just a small difference in terminology here. Rust does, indeed, currently uses a set of bindings written to file rather than directly use a C header file, while languages like zig do the same thing presumably in memory. That seems to me to be pretty much an implementation detail. As Rust has now automated the binding generation, it is also possible to macro the process out and create a "c_import" statement in the same way that Zig has "@cimport".

Rust can call C, it can call an arbitrary function in C, it can handle arbitrary data structures created in C and it can create C any data structures on the Rust side and pass them to C. You do not need to create shim code in C, using any particular interface or object to achieve that.

You do need to add extra code to describe the additional semantics that Rust uses to define safety which C cannot do. I am not sure that I can see the easy alternative here.

Why do you think you cannot call C directly from Rust? I am guessing we are talking about two different things. For Rust, you need to add a header to your rust file to describe the function that the C library offers, then away you go. Rather like C actually, which uses header files.

Not sure where SWIG comes into this. AFAICT, linux is using bindgen. This just transforms C header files into Rust ones as part of the build process. (and why, I hear you ask, can't rustc just consume C header files?). As far as I can tell, Rust in Linux only uses generated bindings. The file "binding.rs" just imports the generated files. So I think you are wrong that macros (on the C side presumably) and non-opaque APIs are the issue there.

The Rust safe abstractions are not the same thing as a bindings. They are the bit that takes you away from unsafe code that is the result of the direct C bindings.

Zig looks nicer than Rust for its role of C integration I agree (I make no comments in general, since I haven't used zig properly). It can directly reference C header files and the compiler will even handle building of C source for you for mixed projects. So, there is a bit more set up there. I expect that Zig would still require something equivalent to the Rust abstraction layer to make life easier for downstream Zig developers; difficult to say, as there is no "zig for linux" project yet. Maybe there will be.

Re: Rust is snake oil and its proponents are pushy chancers..

Including a new language was always going to come with some effort. So nothing is really changed there. But there have been many patches, and lots of work, and occasionally there has been some argy-bargy. And lots and lots of angry people on social media, but then that is modern life; I wouldn't draw too many conclusions from this.

You can call C directly from Rust. Or you can autogenerating bindings which reduces the amount of typing and makes the use of C more naturalistic syntactically in Rust.

The bit that takes the work is to make a safe abstraction over the C interface. This part is explicit about things that C is often implicit about: can a value be null or is it guaranteed; what is the lifetime of a pointer; do certain values represent errors.

I am not sure what tiny C front end you would want, nor where you would bolt it.

Re: Rust is snake oil and its proponents are pushy chancers..

Found wanting in what way? Rust in linux is in the kernel tree.

Re: Rust is snake oil and its proponents are pushy chancers..

The kernel developers who started R4L started the project because of their interest in memory safe languages and specifically Rust. They thought that the project would benefit from Rust.

The social engineering that you speak of is that they started with an RFC, had lots of discussions and got the agreement to start that process, rather than telling them to fuck off.

I think what at least one person is finding tiring, is having the same argument again and again. Do or do not as Yoda would say.

Re: "Rust project ... burnout is shockingly high. "

I have been using Rust for a while now, along with other languages. It choose it for a particular project because it was fast with good tooling. Since I started it has also gained good python integration which is what I needed. Most of the people in the Rust community are using Rust for their own reasons.

I haven't really seen much of the quasi-religious fervour that you are speaking off within the Rust community. Indeed, the rust forums have quite a strong response against it; as well as good policies that are very welcoming to newcomers. When I was new to Rust, I found that very helpful.

I am amazed by the amount of discussion it seems to cause outside, with lots of people piling in, often with very vociferous arguments against. Well most of the r4l developers involved just carried on, I can see why the "cancer" argument irritated one person involved.

Many people are working on these sort of options. The problem is that even though Rust is young it has still had a decade of work on it. New languages would likely face all the problems that Rust does in terms in early stage instability and change. And, while languages like zig allow much tighter integration of the code base (i.e. mixed in the same file) they will still bring all the issues that multi-language builds do.

We will see how it does. As you say, the big question is where R4L will go after drivers. We will see something more substantial? And what would that be?

'Key kernel maintainers' still back Rust in the Linux kernel, despite the doubters

Re: If I understand the logic, I understand the reasoning...

Why would they have a rust toolchain? Because they are kernel developers and having a rust tool chain enables them to see breakages early.

Why would they know how to use it? They don't need to know that. You install it, and the build system uses it.

Why would they know how to fix errors? They might, they might not. If they don't, then there are options, including adding a new maintainer who takes care of the Rust part, or they ask the r4l people, or in the extreme cases they leave it till it breaks in staging and it will get fixed there.

No one is arguing that adding a second language comes with no cost at all and to expect that is unreasonable. Yes,overtime, it is likely that the main scalable approach is for many maintainers to bite the bullet and learn enough Rust to maintain the safe abstraction. Would you be worried about that? Learning a new language is not that much of a biggie, compared to the technical expertise required to work on a kernel in the first place.

Re: If I understand the logic, I understand the reasoning...

As far as I can tell Miguel Ojeda, who started the R4L project has been contributing to the kernel since around 2006. So, only 19 years.

Re: If I understand the logic, I understand the reasoning...

They thought it was technically feasible because what you say isn't true.

Rust uses a tool could bindgen which, well, generates bindings automatically based on the C header files.

It is not these interfaces that are being manually maintained. It is the safe abstraction that is being maintained.

Think of it like this. A C function might return a pointer. The Rust bindings will also return a pointer. But that is problematic because in Rust all pointers are unsafe, because Rust cannot know whether the pointer is still alive, or even if it is guaranteed to be a pointer rather than just null. That semantics is not in the C header; if it is anywhere it will be in the documentation, or else it must be inferred from the reading the C code.

Rust in the kernel could leave every Rust client to make that decision for itself. Or it could provide a single safe abstraction that, for example, distinguishes between a value that is known and a value that might also be null. Downstream clients of the Rust safe abstraction can now use safe Rust.

Your last sentence does not really make sense. Why would the Rust in linux folks, many of whom have been long term kernel contributors from before r4l was a thing, want to make the project they are working on fail?

Re: If I understand the logic, I understand the reasoning...

The difference being? I mean, you can just recompile the Rust code to.

I agree that there might be changes that are source level compatible changes in a C API -> C client situation that are not source compatible in a C API -> Rust client situation. How frequently will that happen.

Re: If I understand the logic, I understand the reasoning...

This is true with any downstream code. Any driver using dma, for instance, could break with an upstream change.

There is a difference because this is in Rust. The maintainer needs a rust tool chain installed or they will not find out about the breakage to latter. The rust for linux people have offered solutions -- either add a new maintainer to the system, or accept some breakage in staging because Rust for linux is new, where the rust-for-linux folks will fix it. Over time, the expectation would be that the former of these will become the main route.

It is inevitable that the introduction of any new language will come with some cost, as would the introduction of any new tool chain (such as clang). The question is whether the value is greater than the cost; eventually that decision will have to be made on a whole kernel basis but for now, it appears to be one subsystem at a time. I can see why some people get a bit frustrated with this.

'Maybe the problem is you' ... Linus Torvalds wades into Linux kernel Rust driver drama

Re: Fair comment by Linus

The latter of these is the case. Kernel developers don't even need to install Rust. The kernel build will autoconfig the rust build away.

Any changes that they write that break the Rust wrappers will break in staging where it will be fixed downstream, where the Rust developers will fix it, just as any downstream use of internal APIs will fix their code in response to change.

There is additional load on maintainers: they have to choose whether to accept unexpected breakage in staging; or they have to install a Rust tool chain. That is inevitable as soon as any Rust code is accepted into the kernel. It is, effectively, the same issue as supporting a second build tool chain such as clang.

What must be fairly tiring for the Rust developers is it appears they have to have exactly the same discussion with every subsystem developer.

Six vulnerabilities in ubiquitous rsync tool announced and fixed in a day

Re: rsync has two weaknesses

Rsync and unison are fundamentally different. Unison understands which direction files should be transferred in and when there is a conflict. That requires keeping a history.

Rsync just looks at the status quo. It will do bi-directional sink perfectly well, but if you are not carefully about what you tell it to do, it will either delete data or restore files that you wanted to delete.

systemd begrudgingly drops a safety net while a challenger appears, GNU Shepherd 1.0

emacs and guile

The plan was never to port all the emacs-lisp code to guile. The guile VM is multi-language so the idea was to place the Emacs lisp VM with guile. The C layer would get called as it does now just by guile. The big advantage of this is guile is a compiled VM rather than a interpreted (but byte compiled) language like Emacs lisp. So a lot faster, in theory. Although as Emacs now also supports native compilation through a JIT (being used ahead-of-time, if that makes any terminological sense) that is perhaps less of an advantage than in the past.

The US government wants developers to stop using C and C++

Re: Why?

This runs completely counter to my experience. The rust forums have been extremely helpful, with some folks going to a lot of effort to answer even in depth technical questions.

In fact, they have a strong policy that says "don't tell people to do their homework". The logic is that if you don't want to answer a question, you don't have. Just move on rather than take the time to say it shouldn't have been asked in the first place.

Re: No, of course I've no idea if this remotely resembles the actual syntax used...

It doesn't resemble the actual syntax. The largest block that you can put unsafe on is a function. Making every function unsafe would be a complete PITA.

UK ponders USB-C as common charging standard

Re: What next?

You could build a USB-C with an outer casing that fulfilled the rugged requirements with the actually power going through the USB still. When you didn't need the rugged, you could open the casing manually and still use a normal USB-C connector. Kind of like the XLR/Audio jack combined socket, although that is for compatibility.

Ultimately, though, you have to wonder whether the better solution would be just to use wireless charging. The most robust connectors are surely the ones you don't need at all.

Re: What next?

"In theory. Whether anyone implements that properly in practice is a different question."

They do. I use a multiport USB B/USB C charger. The ports and cables are capable of supporting different power output. I can plug in my laptop at 45W, or a lower power device at 2W and it all works. User facing issues are minimal. Only some of the cables with a USB C ending will charge at 45W, so you have to know which ones work. And, we have one and only one device that refuses to charge at all of USB-C/PD to USB-C; it has to use USB-B or a dumb USB-C; why the PD doesn't just default to 2W charging I don't know.

It's been great; a single charger in the kitchen and we can do everything -- laptop, tablet, phone, powerbanks, bike lights. All of a single wall socket, kept in a wire basket with charging leads coming out everywhere.

Torvalds weighs in on 'nasty' Rust vs C for Linux debate

No that isn't the problem.

"Requiring", "responsibility" -- this is the language of formal contracts. It's not the right thing within a single project which progress with social norms.

In any project there is a degree of obligation between upstream and downstream code. If you use someone elses API, then you have to fix your code if the API changes; that is your responsibility. But, whoever owns the API has a responsibility to think about the impact they have on you when changing that API.

The Rust people are building safe abstractions to large parts of the kernel. Which means that they are downstream of many parts of the kernel. Of course, maintaining those abstractions will be done by the people who know Rust; but that doesn't mean it can have no impact on the C development at all. But this is not different from when someone adds a new bit to the kernel in C.

Software dependency graphs may be unidirectional, but the social dependency this introduces are not.

Re: Too many compilers

This is the reason that Rust is not required to build the kernel, I think. You can still build a working version without. It's also (one of) the reason that there is work on GCC to make it compile Rust.

As Linus says, they have been at this for two years, which isn't really very long. There will be a long road till it becomes a required part of the build.

Upgrading Linux with Rust looks like a new challenge. It's one of our oldest

Re: Is this the horse for this course?

It isn't going to require core developers to convert. But as a Rust API is likely to have less undefined behaviour and certainly will place different requirements on the users and implementors of that API, it is going to require more clarity about the way things work.

When ever you rewrite something, try to add a new language or just have a new developer come on board, you are going to uncover corner cases, or unwritten assumptions that you didn't know or care that you were making. I think that this is all that happened here. Whether core developers want to engage with that process or not will depend on how much the value the inclusion of Rust. Some just won't like it; otherwise might be more worried about something else.

It's hardly surprising that in this process there are going to be some personal falling out.

LLM-driven C-to-Rust. Not just a good idea, a genie eager to escape

Re: Good luck

You do wonder a bit about this post. The author spent 18 months coding in Rust. Their second big complaint is that there are no stack traces when errors happen. They also complain that the community is crabby and bitchy.

But in the comments it is clear that they acknowledge that there were no stack traces because they weren't switched on, and the crabby community was reddit; the author never looked anywhere else for somewhere nicer.

The other complaint is that the syntax is verbose and the semantics unintuitive in places; well 1 out of 3 is not bad. Maxing Rust less verbose and more intuitive is and has been a thrust of Rust lang development for the last few years.

Rust rustles up fix for 10/10 critical command injection bug on Windows in std lib

Re: Ha! Rust Is The Answer To All Our C Programming Security Issues?

I see more people who seem unreasonably triggered by the mention of Rust making this claim, just so that they can proof that it is untrue.

IPv4 address rentals to mint millions of dollars for AWS

I wish they provided a nice simple and easy mechanism that you can just add IPv6 addressing to your resources.

Am I being naive to think that it should all just work these days?

New cars bought in the UK must be zero emission by 2035 – it's the law

Re: Think of the Grid!

The National Grid have published an article on this. Short answer is that electric cars are not necessarily a problem.

The key points are: a) not everyone charges at the same time, including development of infrastructure to ensure this: b) oil takes a lot of energy to refine, so we should recover 4.5kWh for every gallon of petrol not used and c) electricity consumption is falling from it's peak in 2002 by about 16%, while the grid has remained the same, so we can add 16% of energy use back without problems, of which about 2/3 would be enough for electric car needs.

And, of course, all of this is happening over time. It's not a single point in time. The grid is being rebuilt anyway -- consider recent interconnect with Denmark, new sea routes Scotland to England. If the Tory moratorium on onshore wind was removed that alone might be enough to increase capacity in a way that was (reasonably) distributed across the country.

https://www.nationalgrid.com/stories/journey-to-net-zero/electric-vehicles-myths-misconceptions