This actually sounds like a good idea.

I strongly disagree. I'm going to quote myself from reddit here:

Why would you expect to be able to use an old compiler and new crates? Shouldn't you just pin everything to the old versions? The MSRV aware resolver (that we had stably for a year now) makes that seamless. I don't see why they expect to be able to eat their cake and have it too.

This comes up again and again by LTS fans, be it safety critical or Debian packages. Yet no one have managed to explain why they can't use a new compiler but can use new crates? Their behaviour lacks consistency.

And from a later reply:

Now if they want to fund the maintenance in question, that is an entirely different question (and would be a net benefit for everyone). But that tends to be quite rare in open source. https://xkcd.com/2347/ very much applies.

I found the discussion quite interesting over all: https://old.reddit.com/r/rust/comments/1qcxa9o/what_does_it_take_to_ship_rust_in_safetycritical/ (it is a shame lemmy is so much less active than reddit still).

I think some fixed-size collections and stuff like that would be super nice in core.

If you don't mind using a crate: take a look at the well regarded https://lib.rs/crates/heapless (but yeah, having it in core would be nice, but might be too niche).

An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.

This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an "LTS" release, then crates could be encouraged to keep their MSRV compatible with that release.

But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on "just any" third-party crate at higher integrity levels.

I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn't even be that hard (it's certainly been done in many crates already).

I don’t think cargo-deny alone is enough. And many from Rust ecosystem thinks that if I specified version “1”, it will be enough forever. Many tools nowadays are installed by binstall, so binary will be older and older and won’t receive any updates.

code often contains backticks

I've never seen code contain three backticks though.

I guess your heading logic kind of makes sense but tbh I still hate it.

I like the heading styles! The tildes are unusual but the reasoning is sound!

Thanks for the feedback! The style choices are intentional and all valid CommonMark:

• Heading styles: Setext (===/---) for H1/H2 makes major sections visually prominent in plain text, while ATX (###) is used for deeper levels. This hybrid approach optimizes readability in the raw source.

• Four tildes: Tildes are valid CommonMark delimiters, just less common. They're chosen because code often contains backticks (shell commands, string literals), so tildes avoid visual clutter.

The core philosophy is that Markdown should be readable as plain text, not just after rendering. These choices prioritize scanning structure in a text editor. That said, it's definitely an opinionated style—not for everyone!

Because Hong.

I have the feeling that this wasn't even done properly (e.g. checking default versions only). Using downloads alone is also not a good filter.

I may give this some time tomorrow and provide my own numbers.

Very weird style. Inconsistent heading styles. Four tilde code blocks? That's totally nonstandard. Why?

Yeah unfortunately these numbers don't really allow any conclusions to be drawn at all.

Also they're not really related to supply chain security which is more about deliberate subterfuge. I think the interesting stat there would be how many authors are being trusted typically for each crate.

It would be good to know how these figures compare to e.g. pypi, npm.

Professional software development needs to include a software Bill of Materials to help track and manage things like this. https://www.cisa.gov/sbom

Basically a combination of GFM with a few extensions such as definition lists!

Exactly which flavours of Markdown are targeted/required by this specification?

Stop Forwarding Errors, Start Designing Them was a great read, and I'll definitely be trying Exn.

Every family has that weird cousin (it might be me in our case....)

It's actually a bit rigid because of the filling, but it does look adorable and i love the little guy

lol that squishy form with those eyes look funny

More pictures:

It's about keeping it simple: black and white only, which of course are RGB(0,0,0) and RGB(255,255,255). If you want to use colours, you need a colour selector which is unnecessary fluff at this point. Obviously it'll be a critical element fairly soon, but right at the start of the project it's (arguably of course) less important than the application structure and just getting an MVP together. If you want to do colours before you do File-Open and File-Save that's a valid choice.

Huh, so it's not something simple I have missed regarding why so much software is being rewritten in Rust... I see that appearing so often, so I thought there was maybe a bigger reason I'm not seeing. Anyways, thanks again, appreciate the explanations 👍

How is this literal joke still getting so much engagement?

There's not a great answer to your question and the 'right' choice is going to be situational. The reason to migrate to Rust is simple: fewer possible bugs should reduce maintenance costs. Whether or not migrating functionality between languages makes sense is another can of worms. Is there enough documentation to avoid the nuanced edge cases that are handled by the current solution's code? Is this a simple port, does it only need interface compatibility, or should a larger area of code be modified? If the code is shared how does the rest of the team feel about the potential language?

I do not know what happened re: drama among Linux maintainers but I seen rumblings about it on Lemmy.

Thanks for explaining, didn't know that part about memory safety. I agree, for new apps it makes more sense to pick Rust over C/C++ (unless maybe if you're a C veteran). However, if it's just as fast as C/C++, wouldn't it make sense to leave existing C/C++ apps as they are (as long as you don't want to add new functions)? Not judging, just genuinely curious (especially since Rust hat stirred up some drama among Linux maintainers, from what I have heard)

Rust is spiritually fairly close to C/C++, but with modern convenances like memory safety and ease of concurrency. It compiles somewhat slower but it's compiler errors are more friendly IMO. Rust can be as fast as C++, is also cross platform (eg windows/Linux/Mac) and scales up/down from IoT device level to desktop to seerver applications. If you're going to be writing a lower level app Rust is a good language to look at, but you can also write GUI applications in Rust too.

Here's a decent overview