LWN: Comments on "Defining the Rust 2024 edition"

Defining the Rust 2024 edition

natkr — Tue, 20 Feb 2024 15:05:26 +0000

And that's the beauty of it! Making rebuilding the default makes proprietary libraries largely unviable, while helping exercise the build process of F/OSS ones. Win/win!

Small corrections

deltragon — Tue, 13 Feb 2024 22:18:15 +0000

Two small nits:

Firstly:
> generators — recently renamed in the internal documentation to coroutines to match use of the term outside of the Rust community

This rename happened to distinguish between two things (using the new rust terminology here): generators, which the RFC proposes, which are more limited in scope to the specific use case of iterators (eg. they can not receive inputs on yield, only as arguments), and coroutines, which are the more powerful feature that is currently compiler-internal, where it is used as a basis to implement both generators and async block. The compiler-internal coroutines previously also used "generators" as a synonym - the renaming happened to more clearly distinguish these two.

Secondly:
> the 2021 edition becoming more stable — in the sense that new syntax will now go in the 2024 edition

This is incorrect, on two accounts.
New syntax that is backwards-compatible with existing editions will be added to all such editions - only incompatible changes are confined to a new edition. Also, the 2021 edition had been declared as "stabilised" back in 2021 - so it is just as stable as the 2015 edition now. Incompatible changes to be made after the 2021 edition's release had to wait until 2024, rather than being introduced into the 2021 edition, as this line implies.

Function Pointer cast

mb — Thu, 08 Feb 2024 06:50:19 +0000

> dereferencing an invalid pointer. It's possible to define it perfectly well

Yes. But that probably costs you most optimization opportunities and all parts of the code.
You can have that behavior today by disabling optimization in C.
Not sure, if it's possible in Rust. Probably not. Rust is quite strict about assuming no-UB.

"Coding to the machine" and "getting what the hardware does" is impossible in real programs.

Function Pointer cast

milesrout — Thu, 08 Feb 2024 00:34:00 +0000

Surely the solution to that problem is to fix miri so it corresponds to what actual machines do, rather than try to "fix" code that works fine on real machines but doesn't work on miri? The point of an abstract machine is to abstract away the irrelevant differences in the details between different concrete machines. But all actual targets for Rust have a single address space, at least for code (and most have a single address space for code and data). So there is no actual reason why this should be undefined.

Then again I would say the same thing for the "undefined behaviour" that is dereferencing an invalid pointer. It's possible to define it perfectly well: you get the result of dereferencing it. And if that means that your system faults, then it faults. If it means you read garbage, you get garbage. But it doesn't give the compiler permission to compile out your later pointer validity checks.

Function Pointer cast

tialaramex — Wed, 07 Feb 2024 01:51:37 +0000

Miri. I can convince you, or some committee, but I can't imagine how I'd persuade Miri.

Defining the Rust 2024 edition

farnz — Mon, 05 Feb 2024 18:05:15 +0000

No I did not - I changed the library-provided MAX_BYTES, and rebuilt the library with a smaller version. If the library ABI was stable (as would be the case if C provided a stable ABI), then I'd find that applications built for the older version of the API would work with the newer library. As it is, by rebuilding the library with an ABI change (but not an API change), I've broken all applications that were written against the old DSO, but now dynamically link against the new DSO.

And this is the point - I've done a change that's local to the library (the library's API does not change), that breaks the library ABI, and yet the C language doesn't do anything to stabilize that ABI. You're trying to declare this as somehow "out of bounds" because it shows up that C's ABI is also unstable, unless you take care at the library level to also keep a stable ABI.

Once you're carefully doing a stable ABI for your library, then Rust and C provide similar tools - you can define your ABI in terms of the things that the ELF psABIs (and other platform equivalents) provide, and you know that it's a special module that you need to be careful with. The only difference is that most of C is stuff that lives in the psABI for your OS, but most of Rust does not, and thus when you write your ABI module in Rust, you find yourself feeling much more restricted than you would be if you were writing C.

But this feeling is not an advantage of C - it's that C is sufficiently impoverished as a language (AFAICT, there's nothing in C that wasn't invented by 1960) that you don't have much that isn't already in the psABI for your platform. And that goes double for ELF platforms, since the ELF psABI was defined in terms of the (already well-understood) needs of ld for C and FORTRAN 77, not for anything more modern.

Defining the Rust 2024 edition

pizza — Mon, 05 Feb 2024 17:10:21 +0000

> What should they do instead? Use C? How does that make any sense? Rust has a C ABI.

If you want/need a stable ABI with Rust, you have to present (and/or consume) a C ABI, because because Rust is unlikely to gain a "Stable Native Rust" ABI in the foreseeable future.

Defining the Rust 2024 edition

pizza — Mon, 05 Feb 2024 16:57:33 +0000

> As an application programmer, following the published Application Programming Interface, I don't care what value MAX_BYTES takes; I just know that I must use the named constant MAX_BYTES to refer to it, and my application will do the right thing across the interface.

Sure. And then you went and arbitrarily switched from the library-provided MAX_BYTES symbol to one of your own creation/definition, and complained that it caused problems.

You don't get to arbitrarily change the local definition of something and expect to successfully interoperate/communicate/whatever with something else.

Defining the Rust 2024 edition

farnz — Mon, 05 Feb 2024 16:52:43 +0000

We have to demote to less than what C provides, actually - we have to demote down to the things that are provided by the platform ABIs (Win32, Win64, ELF psABIs, mach-O), and we have to do that in both cases, since there are things in C that are not represented in the platform ABIs, either.

The difference is that much, much more of useful Rust is not directly represented in the platform ABIs, because there's a much bigger chunk of Rust that's more powerful than the platform ABIs directly provide (not least because the platform ABIs originally intended to cover most useful C and FORTRAN code, so were built to provide most of what C needs). But if you want a stable ABI with Rust, you can do it; it's just more obvious how much you're throwing away to get a stable ABI.

Defining the Rust 2024 edition

mb — Mon, 05 Feb 2024 16:51:13 +0000

You see? You have to restrict yourself to a subset of C's possibilities to get a stable ABI.
There is no stable ABI for arbitrary C programs.
Yet, you demand a stable ABI for arbitrary Rust programs.
Not going to happen.

Defining the Rust 2024 edition

farnz — Mon, 05 Feb 2024 16:46:20 +0000

No, MAX_BYTES's value is not part of the API; it's part only of the ABI. The fact that you don't give reasoning for why the value of a constant (as opposed to the constant's name) is part of the API implies that you have an internalised view of API that you define as "the things that affect the C ABI", at which point your whole argument is circular.

As an application programmer, following the published Application Programming Interface, I don't care what value MAX_BYTES takes; I just know that I must use the named constant MAX_BYTES to refer to it, and my application will do the right thing across the interface. It's not until you build a binary that you refer to a concrete value; and, indeed, if C was a more capable language, my header file equivalent would only tell you that there is a constant MAX_BYTES, but you'd not get the value of that constant until you combined that with an implementation. It's just that C lacks encapsulation, so when I tell you in my API that there is a named constant, I also have to tell you what value to use for it - I can't hide that from you.

And your "network protocol" example is exactly why C does not have a stable ABI by default - you have to carefully define your ABI in order to avoid problems, and the only "advantage" C has over Rust in this respect is that the things that you use to define your C ABI are also the full power of the C language, whereas in Rust, they're what you get when you remove significant features (like monomorphized generics) from the language.

Defining the Rust 2024 edition

mb — Mon, 05 Feb 2024 16:44:32 +0000

>That the entire point; to get a stable ABI in Rust today, you have to essentially demote it to what C provides,
>on both the library provider and library user, even if both are written in Rust.

Which makes it no less stable or usable for stable ABIs than C.
I don't really see the point.

We need stable Rust ABIs, because C has a stable ABI?
Rust *has* a stable C ABI.
What's your point?

> "probably in the future" is not something that someone [considering] using Rust today should ever plan on happening.

What should they do instead? Use C? How does that make any sense? Rust has a C ABI.

Defining the Rust 2024 edition

pizza — Mon, 05 Feb 2024 16:32:17 +0000

> Rust does have a stable C interface.
> It's there. You can use it to have stable ABIs.

Well, duh. That the entire point; to get a stable ABI in Rust today, you have to essentially demote it to what C provides, on both the library provider and library user, even if both are written in Rust.

> It will probably happen that a non-generic subset of Rust will be defined as stable ABI in the future.
> Defining a stable ABI for the whole language probably is impossible.

"probably in the future" is not something that someone [considering] using Rust today should ever plan on happening.

Defining the Rust 2024 edition

pizza — Mon, 05 Feb 2024 16:23:09 +0000

> The API remains (both before and after the change) "you must not supply data in chunks larger than MAX_BYTES"

You changed the definition of MAX_BYTES, which is a change to the API -- No ifs, buts, or hand-waveys.

That said, not every change to the API necessarily represents a change to the ABI (for existing stuff), and there are ways to design the APIs to make your example (ie changing the definition of MAX_BYTES) have no effect on the ABI. Just off the top of my head:

1) Give the structure an explicit data length field and use a variable-length structure. This also means one doesn't get to use sizeof(structure) or static allocations.
1a) Instead of a variable-length structure, use a pointer to an aribitrarily-sized blob.
2) Have the application query/be told, at runtime, the maximum size of a given structure/field.
3) Make the structure opaque, with the API providing contstructors/destructors and access/manipulation functions.

For example, the decades-old BSD socket API uses a combination of (1) and (2). I can take a binary that was only ever aware of IPv4 addressing (32-bit addresses) and use it with a library that is aware of IPv6 (128-bit addresses), and it will work. Not because of glibc's fancy symbol versioning, but because the API was crafted with care to ensure that additions wouldn't change the ABI for the older stuff.

Another way of looking at this is that the shared library boundary is akin to a network protocol; a change in MAX_BYTES in your strawman example means the over-the-wire data format will also change, meaning you have to update both sides in lockstep for nearly any change, but with care (eg adding an explicit length field) you can check for a size greater than [your idea of] MAX_BYTES and handle/fail it gracefully.

Defining the Rust 2024 edition

mb — Mon, 05 Feb 2024 16:11:39 +0000

>Meanwhile, in the C world,

Rust does have a stable C interface.
It's there. You can use it to have stable ABIs.

Please compare apples to apples.
It's not correct to compare the toy-ABI of C to something as complex as Rust or even C++ and demand that if C has a semi-stable ABI, then C++ and Rust should also have them with support for the whole type system. They should not. And they can't.

>But going back to your example *API*, it's not well thought out.

Yep. That's the thing here. To have a stable ABI you have to constrain your API. That is true for Rust, that is true for C++ (d-pointer, anyone?) and that is also true for C (#define). Thou shalt not modify the #defined values is one of the rules that you applied.

It will probably happen that a non-generic subset of Rust will be defined as stable ABI in the future.
Just like we can have a subset of C++ being stable.
Simple C-like Rust functions with simple Rust types going in and out can probably be made stable.

But I think today is not the time to do that. We should stabilize the APIs a bit more, before we stabilize a subset of the ABIs. Due to the inter-crate compatibility guarantee between editions, we already have a big constraint on what editions can change. I think it's not the time to constrain that further, yet. Just use a C ABI with simple types, if you need a stable ABI.

Defining a stable ABI for the whole language probably is impossible.

Defining the Rust 2024 edition

farnz — Mon, 05 Feb 2024 14:19:24 +0000

I did not change the API at all - and in a statically linked world, everything works just fine. The API remains (both before and after the change) "you must not supply data in chunks larger than MAX_BYTES"; if I supply you a .a and matching .h for that library, you can statically link, and a simple recompile will fix things if you obey the API as documented (e.g. by reading in at most MAX_BYTES at a time via read(2), then supplying them to this library).

If I was committing to a stable ABI, I'd use a version script (as glibc does) to provide both old and new versions of the symbols, and to do whatever it takes to handle both old and new versions with the same underlying algorithms. This is a lot of work, and it's to the glibc maintainers' credit that they do this work, so that even if they change APIs (not just ABIs), things Just Work.

Part of the problem here is that you've internalised a whole pile of rules around ABI stability, and you're assuming that they're part of the C language - but they're not, they're things that you have to do to have a stable ABI even in C. It's just that in Rust (and C++), the things you have to do to have a stable ABI are much more visibly painful than they are in C, because there's not many constructs in C that don't translate directly to the ELF psABI for your platform (const is one, the preprocessor is another, I can't think of a third off the top of my head). This, in turn, is because the C language simply doesn't have useful features (like generics) which aren't directly representable in ELF psABIs (in part because the ELF psABIs themselves aim to fully define the ABI for a C-like language, and not for something more capable).

Defining the Rust 2024 edition

pizza — Mon, 05 Feb 2024 13:17:16 +0000

> Otherwise, you're claiming that if I reduce MAX_BYTES in the below header file and rebuild the dynamic library that used it, any program that was built against the old definition (and hence the old ABI) will automatically adjust to match:

You changed the *API*, of course you're going to have issues. This is true of _any_ language, static or dynamic; computer or human.

Meanwhile, in the C world, I can take a shared library that is literally over two decades old (and its accompanying header file, which desctives the API) and expect it to JustWork(tm) with my brand-new software and the latest compiler and libc for my platform [1] That's what "Stable" refers to in this context.

But going back to your example *API*, it's not well thought out. But defining "good" APIs is a discipline all of its own.

[1] To be fair, some of that credit is due to glibc's commitment to backwards compatibility.

Defining the Rust 2024 edition

ras — Mon, 05 Feb 2024 10:25:24 +0000

> How about something truly revolutionary and never seen before, like for example a stable ABI and shared libraries?

Right now, I'd settle for a stable set of I/O traits. Not implementations or ABI's, just traits. As it stands, you have to use one I/O library for normal programs, or if you pick an async implementation you've got to use it's I/O library, ditto with green threads. It's enough to make the poor schmuck trying to write some library compatible with everything pull his hair it. Right now, if your library has to do I/O it's damned near impossible to work with everything.

The software world is built on re-use. This multitude of incompatible colours is the opposite of reuse. It's a fragmentation bomb for an ecosystem.

Defining the Rust 2024 edition

farnz — Mon, 05 Feb 2024 10:07:21 +0000

I don't believe that the C world has a stable ABI for arbitrary programs; rather, the C language is sufficiently limited that it's easy to avoid the sorts of things that result in an ABI change.

Otherwise, you're claiming that if I reduce MAX_BYTES in the below header file and rebuild the dynamic library that used it, any program that was built against the old definition (and hence the old ABI) will automatically adjust to match:


const size_t MAX_BYTES=65535;

struct priv_context;
struct context {
    uint8_t buffer[MAX_BYTES];
    struct priv_context *private;
};

/// Allocate a new context. Note that priv_context has entries sized based on MAX_BYTES
struct context * allocate_context();

/// Supply new data to the context; if the input is more than MAX_BYTES, then the behaviour of this function is undefined
void new_data(struct context * context,  uint8_t * bytes, size_t size);

This does not match the C standard I'm used to working with.

Defining the Rust 2024 edition

Cyberax — Sun, 04 Feb 2024 14:52:44 +0000

> But.. that's still using XCode/MSVS?

Not quite. The build description remains in CMake. XCode/MSVS are used to work with the code.

> If the complaint is that the full autotools suite doesn't generate anything other than pure makefiles, that's a technical problem that can be rectified by someone willing to put the work into said feature. [1]

No. It can't be reasonably done in autotools without making them into CMake. It's possible in the same sense as all Turing-complete languages can emulate each other.

> FWIW, a quick bit of googling shows several folks successfully generating iOS libraries for autotools-based projects

Try it for real. It JustDoesntWork without tons of fiddling.

Defining the Rust 2024 edition

pizza — Sun, 04 Feb 2024 14:01:06 +0000

> You write CMakeFiles to describe your library and deps, and then generate an XCode project from it. On Windows, you can generate an MSVS project.

But.. that's still using XCode/MSVS?

If the complaint is that the full autotools suite doesn't generate anything other than pure makefiles, that's a technical problem that can be rectified by someone willing to put the work into said feature. [1]

FWIW, a quick bit of googling shows several folks successfully generating iOS libraries for autotools-based projects -- It's effectively just another cross-compile target. But each (major) iOS/etc version (and sometimes hardware family on top of that) requires a different target tuple and toolchain options that are not easily discoverable, and you need to rinse and repeat multiple times to generate all of the variations that XCode needs. Which is a real PITA.

[1] Granted, it's unlikely that folks with high levels of autotools know-how are motivated to add support for probably the most FOSS-hostile platform widely deployed today. And adding Windows support requires a _lot_ more work than just changing the build system.

Defining the Rust 2024 edition

pizza — Sat, 03 Feb 2024 12:24:10 +0000

> The reality is that these world rebuilds rarely are an issue.

They are if you don't have the complete source code to _everything_.

Which, when you are consuming commercial/proprietary libraries, you often (if not usually) don't.

Defining the Rust 2024 edition

pizza — Sat, 03 Feb 2024 12:22:15 +0000

> It is just not possible to have a stable ABI for *arbitrary* programs. That just as impossible for Rust as it is impossible for C++ and even C.

The entire C world disagrees with you, using the fact that it _exists_ as evidence.

Defining the Rust 2024 edition

mb — Sat, 03 Feb 2024 09:36:40 +0000

>Ah, Rust code has by definition no security problems.

Really? Nobody said that in this whole discussion.
I said that this particular CVE would probably not have existed, if the function was written in Rust.
Look at it!
It is a classical buffer overflow. Buffer overflows and integer overflows resulting in buffer overflows are *the* most common thing when it comes to security problems.
This bug would almost certainly not have been exploitable in Rust.
It would have been garbage data in -> garbage out (program termination).

But you know what? You are actually right.
Rust code can also have security problems, of course.
Rust only tries to make certain classes of bugs impossible or much much harder to express.

But it is no coincidence that these classes of bugs make the majority of security bugs.

And that is what makes Rust code have *almost* no security problems by definition.
Of course you can still incorrectly implement your security checks for your door entry mechanism. But Rust ensures that it won't outright blow up right into your face with UB.

Defining the Rust 2024 edition

mb — Sat, 03 Feb 2024 09:19:02 +0000

Guys, can we please all educate ourselves a bit? Please?

It is possible to have dynamic libraries with Rust.

It is just not possible to have a stable ABI for *arbitrary* programs. That just as impossible for Rust as it is impossible for C++ and even C.
It doesn't make any sense to link generic libraries dynamically. It doesn't make sense in Rust and it also doesn't make sense in C++ (templates, preprocessor) or C (Preprocessor generics). These kinds of libraries always have to be statically linked.

But if you fear world rebuilds as an issue for your library, you *can* avoid that by carefully making it a shared library. No different from C++ or C.

The reality is that these world rebuilds rarely are an issue.
I don't know of a single case of stdlib bug that made a world rebuild mandatory. There probably are a couple of these incidents, though.
And that is simply because certain kinds of bugs cannot happen in Rust. Because either the compiler outright refuses to compile it, or the programmer's mindset when writing unsafe Rust is completely different from programming C.

Even if a CVE is assigned to a certain bug in a central library, it rarely affects any *actual* program. In Rust programs CVEs are assigned for all unsoundness bugs. An unsoundness bug *could* result in an invalid program iff the program exploits the unsoundness. But in practice that rarely happens, because usually such code would not be idiomatic Rust code.

Lots of really bright people who wrote great software are commenting here. I really appreciate that and it makes LWN kind of unique.
But if you have no clue about Rust, please try it. Please educate yourself. It's not a shame. It will bring you forward. And it doesn't mean that you will have to like Rust. But you will *know* it and you will not look like a fool in discussions like this anymore.
(And no, I also don't know everything about Rust and I might also have commented incorrectly at times).
Rust is very different from C. You cannot simply apply your existing C knowledge to Rust. It will automatically result in such ridiculous discussions as seen here.

Defining the Rust 2024 edition

jschrod — Sat, 03 Feb 2024 01:43:14 +0000

> I swear, this really does come off as a "I don't care about the plights of farmers; I get my food from a supermarket!"

This should go into LWN's quote section.

Defining the Rust 2024 edition

jschrod — Sat, 03 Feb 2024 01:16:28 +0000

Ah, Rust code has by definition no security problems.

This is not worthy to discuss.

*plonk*

Defining the Rust 2024 edition

jschrod — Sat, 03 Feb 2024 01:13:38 +0000

> It costs programmer time, while recompilation only costs machine time.

And that is, in a nutshell, why DevOps is so important.

It teaches developers the problem that operation has with such fantasies.

Function Pointer cast

mathstuf — Fri, 02 Feb 2024 17:58:32 +0000

> I can't begin to imagine how you could convince the machine that this definitely works.

Do you mean abstract machine here? Or perhaps the model (like MIRI)? The compiler? Because the hardware machine doesn't care and will try whatever you point the instruction pointer at (well, I suppose there are some security mechanisms that can say "no" these days).

Defining the Rust 2024 edition

mathstuf — Fri, 02 Feb 2024 17:48:41 +0000

Sure, if you don't use generics. As soon as you want `Vec<MyType>`, where does that ABI live? Because `MyType` could just as easily be `YourType` and your crate just didn't need `Vec` of them (or the methods I use). If you want to make it more complicated, `NonStdContainer<YourType>`.

Defining the Rust 2024 edition

khim — Fri, 02 Feb 2024 16:44:46 +0000

> I'm sure auto*conf* could be coaxed into doing this, but I have no idea how one would automatically port any auto*make* usage to it.

With Kati this should be possible, someone just need to intergrate it into all that automake machinery to teach it to properly rebuild ninja files when that's needed.

Not sure if anyone have ever done that or not, though.

Defining the Rust 2024 edition

Cyberax — Fri, 02 Feb 2024 15:52:58 +0000

Thank you for CMake!

All C++ build tools suck, but CMake at least works properly. And the backwards compatibility is great.

Defining the Rust 2024 edition

mathstuf — Fri, 02 Feb 2024 13:02:52 +0000

Oh, and generating `build.ninja` files is a quite nice build perf bost that is easily attainable with CMake. I'm sure auto*conf* could be coaxed into doing this, but I have no idea how one would automatically port any auto*make* usage to it.

Defining the Rust 2024 edition

mathstuf — Fri, 02 Feb 2024 13:01:08 +0000

> I've never encountered a feature that cmake has and autotool doesn't have.

Supporting MSVC as a compiler[1]? C++ modules support is also something I'm interested to see how autotools will support (I implemented it in CMake; there are things that really need proper modelling that autoconf doesn't provide AFAIK).

FD: CMake developer

[1] The FAQ still has this as a TODO at least: https://www.gnu.org/software/automake/faq/autotools-faq.h...

Defining the Rust 2024 edition

josh — Fri, 02 Feb 2024 06:51:14 +0000

> That's the point, though - for a stable ABI, you should be forcing yourself to consider every exported item with care

That's not the same issue I was raising, though. I *absolutely* think that you should consider every part of your public ABI with care. However, that does *not* mean I want every public ABI to have to use raw pointers, eschew things like Option and Result and String and Vec and HashMap, be unable to provide objects that have methods, be unable to accept parameters that can be anything-that-implements-a-trait, and many many other features.

crabi will solve some of this for cross-language ABIs, and there's another effort to provide a much broader stable ABI surface that's just for Rust-to-Rust calls, but in both cases it'll take a while before we get there. And in the meantime, I don't think it's reasonable to require that people provide a C-only ABI just so it can be a shared library; that'd be a substantial step backwards.

Defining the Rust 2024 edition

dankamongmen — Thu, 01 Feb 2024 23:54:00 +0000

it required some effort (and, to be fair, our windows builder is currently reporting failure), but i was able to get Notcurses building on Windows and OSX using cmake and portable c. admittedly, it's not using GUI toolkits, but it's definitely a nontrivial, unix-first, non-pure-computational library.

Defining the Rust 2024 edition

Hattifnattar — Thu, 01 Feb 2024 16:19:33 +0000

> That's not really true, it works just fine in Perl, Python and Ruby too

Maybe I misunderstand what you are talking about. But in my experience, pretty much everybody who works on serious Perl applications rely on CPAN for getting modules, not their Linux distribution. I know that distributions try to package Perl modules, and I assume somebody uses it, but in real life I've seen only quick-and-dirty scripts and one-liners utilize that. Of course it's only one guy experience...

Defining the Rust 2024 edition

Hattifnattar — Thu, 01 Feb 2024 16:09:33 +0000

It may be just the fact that a lot more people joined the ranks of programmers.

Early on, programming was an elite undertaking, with people practicing it having a mindset closer to scientists. It was elite job, commanded elite compensation (not necessary monetary, esteem too). The "industry" also had been largely driven by people with more-or-less engineer or scientist mindset.

Now software is a real and huge industry, programmer work is commoditized, the whole thing is more and more run by people with "financist" and/or "bureaucrat" mindset, "buccaneer" in the best case.

There are still "islands of quality" in this mess, mostly dealing with foundations. But they cannot completely isolate themselves from the overall dynamics. However, understanding it can can help to draw some boundaries and do better in specific areas/projects etc.

Defining the Rust 2024 edition

bluca — Thu, 01 Feb 2024 14:33:41 +0000

It is a Rust-specific problem, because I am talking of Rust-as-the-ecosystem, not Rust-as-the-language. It's only the corporate-driven ecosystems of Rust/Golang/Node that have this problem in reality. And that's because the corporations pushing for these ecosystems have no interest nor incentive in solving it, and don't care about the use case at all, they just assume someone will make it work somehow on their own time. This does not and will not scale, and at some point it will explode badly.

Defining the Rust 2024 edition

farnz — Thu, 01 Feb 2024 10:59:47 +0000

See also a subset of the fuss around the EU's Cyber Resilience Act; not the people talking to MEPs and national Commissioners about getting the details right (e.g. ensuring that I can't be held liable if you use my software for a purpose I did not advertise it as suitable for), but the people arguing that any form of liability for defects in software will destroy the software industry completely. In effect, they're saying that the software industry (including embedded) cannot exist if software vendors can be held liable for faults in the software they sell.