> In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.

This exists in the nightly edition of Rust, but is unlikely to become a feature in its current form because the alternative of "Storages" seems to be a lot more flexible and to have broader applicability.

This is a very interesting feature, especially if comptime can become a true language superset with features such as the ability for seamless type-level programming, leveraging `const fn` code throughout. This would unlock the potential for having true dependent types in (the comptime portion of) Rust programs, and write arbitrary end-to-end compiler-verified proofs about code that will ultimately run in the final program.

> Rust is no doubt difficult to learn, there are many concepts and a lot of syntax

People love to say this, but C++ is routinely taught as a first programming language to novice programmers (this used to be even more clearly the case before Java and Python largely took on that role) and Rust is undoubtedly simpler than C++.

C++ as First Language seems like an especially terrible idea to me. Maybe I should take a few months and go do one of those courses and see whether it's as bad as I expect.

The nice thing about Rust as First Language (which I'm not sure I'd endorse, but it can't be as bad as C++) is that because safe Rust ropes off so many footguns it's extremely unlikely that you'll be seriously injured by your lack of understanding as a beginner. You may not be able to do something because you didn't yet understand how - or you might do something in a terribly sub-optimal way, but you're not likely to accidentally write nonsense without realising and have that seem to work.

For example yesterday there was that piece where the author seems to have misunderstood how heap allocation works in Rust. But, in safe Rust that's actually harmless. If they write their mistake it won't compile, maybe they figure out why, maybe they give up and can't use heap allocation until they learn more.

I haven't thought too hard about Zig as first language, because to me the instability rules that out. Lecturers hate teaching moving targets.

As somebody that "learned" C++ (Borland C++... the aggressively blue memories...) first at a very young age, I heartily agree.

Rust just feels natural now. Possibly because I was exposed to this harsh universe of problems early. Most of the stupid traps that I fell into are clearly marked and easy to avoid.

It's just so easy to write C++ that seems like it works until it doesn't...

I don’t know anyone that learned C++ first. Maybe I’m younger in generations, but Java was the first thing everyone learned at my university.

I belonged to the generation that graduated into the rising dotcom boom. Around that time, lots of universities taught C++ as the first serious language. (Some still started with Pascal.)

The main thing a lot of had going for us was 5-10 years of experience with Basic, Pascal and other languages before anyone tried to teach us C++. Those who came in truly unprepared often struggled quite badly.

Just after Pascal vs C craze in mid to late 90's for sure. That is quite a different C++ than the one of today however.

I gave up on a C++ after trying to learn on and off for years. LNK1009 still haunts me in my sleep. I am now an avid self-taught rust programmer and I feel like I have the power to create almost anything I can imagine using rust. This is great for hobby people

That's true, but as someone that doesn't do much rust, C++ is a language where there are fewer restrictions and you can use little parts of the language, whereas Rust is supposed to be a simpler language overall, but with more concepts to learn up-front to prevent things that happen where there are no rules....

You can use "little parts of the language" in Rust too; the cleanest and most foundational part of Rust is pure value-based programming with no mutability or referencing at all, much like in a functional language (but with affine types!). Everything else is built quite cleanly on top of that foundation, even interior mutability which is often considered incredibly obscure. (It's called "interior" because the outer cell's identity doesn't really mutate, even though its content obviously does.)

Precisely.

You can subset C++ and still knock out a program.

You cannot subset Rust and still create a program.

You can absolutely make a complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.

But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.

Discussions about Rust sometimes feel quite pointless because you can be several replies deep with someone before realising that actually they don't know much about the language and their strongly-held opinion is based on vibes.

Exactly. Claims like "even without dealing with a single reference/borrow."

When you have this stuff in "Hello World":

Egui Hello World:

    ui.add(egui::Slider::new(&mut age, 0..=120).text("age"));

Ratatui Hello World:

    fn render(frame: &mut Frame) {

or

  fn run(mut terminal: DefaultTerminal) -> Result<()> {
      loop {
          terminal.draw(render)?;
          if matches!(event::read()?, Event::Key(_)) {
              break Ok(());
          }
      }
  }

And I didn't even break out the function chaining, closure and associated lifetime stuff that pervades the Rust GUI libraries.

When I can contrast this to say, ImGui C++:

  ImGui::Text("Hello, world %d", 123);
  if (ImGui::Button("Save"))
      MySaveFunction();
  ImGui::InputText("string", buf, IM_ARRAYSIZE(buf));
  ImGui::SliderFloat("float", &f, 0.0f, 1.0f);

which looks just slightly above C with classes.

This kind of blindness makes me wonder about what universe the people doing "Well Ackshually" about Rust live in.

Rust very much has an enormous learning curve and it cannot be subsetted to simplify it due to both the language and the extensive usage of libraries via Cargo.

It is what it is--and may or may not be a valid tradeoff. But failing to at least acknowledge that will simply make people wonder about the competence of the people asserting otherwise.

This seems like a very strange position, code written for Rust in 2015 still works, and in 2015 Rust just doesn't have const generics†, or async, or I/O safety, so... how is that not a subset of the language at it stands today ?

† As you're apparently a C++ programmer you would call these "Non-type template parameters"

You can solve this in the general case by implementing the typeclass for the coarser equality relation over an ad-hoc wrapper newtype.

Well it isn't a good call. This is the kind of code that OOP makes people write.

Rust does not require GC-less memory management. It supports reference counting out of the box, and reference counting is a kind of GC. It's not inherently any harder to use than Swift (another memory-safe language) which plenty of average developers use to code for Apple platforms.

I don’t think it’s a useful observation. Lots of people come to Rust from OOP languages and try to make everything `Arc<dyn Interface>`, and it immediately fails, to their great frustration.

Do not do this.

I think it is significantly harder to use than Swift, and inherently so.

You can make an argument that .unwrap() should have no place in production code, but .expect("invariant violated: etc. etc.") very much has its place. When the system is in an unpredicted and not-designed-for state it is supposed to shut down promptly, because this makes it easier to troubleshoot the root cause failure whereas not doing so may have even worse consequences.

I don't disagree but you might as well also manually send an error to f.ex. Sentry and just halt processing of the request.

Though that really depends. In companies where k8s is used the app will be brought back up immediately anyway.

Kakoune and helix are modal editors. They're largely based on a text selection mode (like the `v` and `V` commands in vim) with commands acting on the selected text, so they're somewhat more intuitive than vi or vim, but the notion of distinct 'modes' is still key to the workflow. Fresh is a mode-free editor; much like nano, Emacs or the new Rust-based MS Edit.

Isn't that just Scintilla-based? It's a bit outdated these days, e.g. missing LSP support.

The main issue with "fundamental" is that it's currently unstable, but a stable version of it could definitely be useful for lessening the "orphan rule" constraints on implementing traits. Probably would want a different name such as #[deorphan] though.

It's almost never the case that memory is uniformly accessed, except for highly artificial loads such as doing inference on a large ML model. If you can stash the "cold" parts of your RAM working set into swap, that's a win and lets you serve more requests out of the same hardware compared to working with no swap. Of course there will always be a load that exceeds what the hardware can provide, but that's true regardless of how much swap you use.