For my first brush with rust i decided i’d do some graph processing - a topic i’ve historically written buggy code for and i wondered if all the hype around rust’s compiler might help. Experienced rust people know where this is going but suffice to say i WOULD recommend this for someone new to rust if you want rapid exposure to what the borrow checker can and can’t do for you, for a rapid introduction to Rc & Arc, along with Box etc. I think i got a quicker introduction to rust by picking a hard use case.

Source: I have written for them in the past.

There's nothing inherently bad or wrong about unsafe Rust. It just leaves it up to you to manage invariants like lifetimes and aliasing contraints – just like in C.

All of those things are possible in Rust. But they're not easy or approachable.

Nothing precludes designing a Rust string that way. You're still designing the mutation interface of the collection, and having a `&mut` to a structure doesn't really give you anything if the structure doesn't allow mutations. Hell, you could actually design your own pseudo-string, which derefs to an immutable string, and only provides for a select number of mutations.

But, given Rust's rules around mutation, what useful property would that yield exactly? I think that's one of the most interesting effects of Rust's strict ownership, very much an "if a tree falls" situation: if you mutate a string in place but there's no way for anyone else to observe that mutation, does it matter?

I can imagine that "append-only strings" would be useful in a world of multiple-ownership where you could delay COW copies without affecting co-owners (though even that seems… somewhat limited), but that's not really a thing in Rust. Given the cow-ownership would be not one but two layers of external wrappers (an Rc/Arc pointer, and some sort of internal mutability shim), it's not like you could not flatten the entire thing and build thread-safe append-only COW pseudo-strings.

But in Rust the distinction is actually about shared vs exclusive access. This is the aspect that really matters for safety. Access is properly of the code, not data, so it can be dynamic from data's perspective (the same data can be borrowed exclusively or not at different times)

When you have exclusive access, immutability becomes irrelevant, because nobody else can observe the mutation (so e.g. exclusive reference to a Mutex can skip locking!)

OO makes a lot of sense in hierarchic structures.

With that in mind, this pattern cleanly maps onto a trait with default implementations for methods plus several structs that implement the trait.

Performance-wise this is the same as a vtable generated by c++ and doesn't require creating more entities.

Instead of making a parent class that has a few key methods you need (e.g. send, recv) with the signatures (e.g. takes a pointer, returns a number), one can encode the use of those functions in a concept (e.g. a "socket" concept). This decouples the implementation from the use in the method, with the one big advantage being that it is easily testable -> no more need to carefully craft type hierarchies to carefully be able to substitute some mock object when you can just directly call it!

OO hierarchies certainly still have their place (even though so many conference talks seem to be about getting rid of them), but I'm glad I can relegate them to a dark corner of my toolbox until I absolutely need them.

In fact, come to think of it C++ concepts are basically Rust traits!

  trait Test {
      fn value(&self) -> i32;
  }

  impl dyn Test {
      fn multiplied(&self) -> i32 {
          self.value() * 2
      }
  }

This time, it's going much better and I've managed to build something non-trivial. I quickly ran into the self-referencing issue. A simple structure to hold an [normalized] phrase and a list of words within that phrase:

    struct Input<'a>{
      words: Vec<&'a str>,
      phrase: String,
    }

Something else I'm surprised the article didn't mention is the combination of `Box<dyn X + Sync + Send>` which is a mouthful - both in terms of having to declare a type with this, and in terms of everything is implies/encapsulates.

The issue is that you have references to the String (it's borrowed). That means it can't change, which isn't/can't be expressed in this struct. Imagine clearing the String: Suddenly all references in words are invalid which means you're referencing something invalid, very much not memory safe and a big rust no-go

    struct Input {
        words: Vec<(usize, usize)>,
        phrase: String,
    }

    impl Input { 
        fn word(&self, i: usize) -> &str {
            let (first, last) = self.words(i); 
            &self.phrase[first..last]
        }
    }

Now even if self.phrase is resized, you never get memory unsafety, because the `self.phrase[...]` does a bounds check and panics on out-of-bounds. So the worst you can get is a "logic error" in your program that shows up with a really nice backtrace that's super easy to debug, instead of a miscompiled program (due to UB) that's often very painful to debug.

So sure, you don't get "self referential struct with references" in Rust. But so what?

The fix for when you want this is always the same: use offsets like I did above. Offsets are much better than any kind of pointer, because they allow you to just "memcpy" the struct around (the address of a field changes on move and copy, but the offset to that field from the beginning of the struct always remains constant).

If you were to use a pointer to a field, you'd need to correct that pointer during copies and moves. C++ allows this, and this "feature" has many undesirable consequences for Rust:

- moves in Rust are O(size_object), moves in C++ can be of any algorithmic complexity, so any algorithm that moves has to take that into account this

- rust collections have one code path, C++ collections have two code-paths: one for objects that are "simple" to move, and one for objects that are "hard" to move

- move constructors that throw in C++ interact with exception safety in complicated ways

- probably many many more interactions that I'm missing here

There might be ways to improve the ergonomics of self-referential structs in Rust, but given that offsets are simple and always work correctly without many downsides, whatever improvement one considers for Rust would probably not be worth it if it has any of C++ downsides.

The "transfer" crate allows for this, though not in a way that's directly compatible with C++ move. (The latter has been discussed somewhat in https://mcyoung.xyz/2021/04/26/move-ctors/ but that's only a first look at the problem area, not aiming for 100% accuracy just yet.)

Offsets cause bugs when you do things like assume your strings are of a particular length; that’s why they’re a bad choice.

Use a crate that provides a safe abstraction, don’t roll it by hand yourself, and the safe abstraction can be implemented in whatever way you want; but it’s not safe if it doesn’t enforce the invariants.

This isn’t really true, as the character of bug produced is quite different between the two cases. If you make a mistake with offsets, you’ll get a runtime panic that tells you exactly where the problem occurred. If you make the same mistake with raw pointers, however, you’ll get corrupted memory somewhere which won’t necessarily show up as a problem until long after the erroneous code is executed.

Yes, there is a distinction, yes one is worse than the other, but if you got a panic, your application terminated.

You’re screwed either way, web server or desktop app; fortunately there’s a simple solution: use whatever means you like to write a safe abstraction that enforces invariants.

I’m not advocating particularly for unsafe code; but avoiding unsafe and writing code that blatantly panics at the drop of a hat is ridiculous.

Invariants should be enforced by the type system.

I don’t care how; if you’re not doing that and just assuming your strings are shorter than 256 characters, you’re writing code that is unsound.

Not really.

If the application terminates, it is infinitely easier to catch this during testing.

If the application silently continues, that might be an exploitable security vulnerability, might result in corruption of pretty much anything (data-bases, loss of user data, ...).

Pretty much everybody with an exposed web-server would prefer it to terminate with a nice debug message over the alternatives that using raw-pointers would cause.

> you’re writing code that is unsound.

No you are not, code using offsets is perfectly sound because it does not exhibit undefined behavior (which is how "soundness" is defined in Rust).

Your suggestion of using unsafe instead of offsets here would indeed be unsound. Don't do that.

> but avoiding unsafe and writing code that blatantly panics at the drop of a hat is ridiculous.

This is the most retarded thing I've read all day. `assert` is a tool used on _many_ standard library API to ensure soundness.

> I don’t care how; if you’re not doing that and just assuming your strings are shorter than 256 characters, you’re writing code that is unsound.

I really have no idea why you sound so angry, but the claim that someone anywhere in this thread is "assuming your strings are shorter than 256 characters" is completely made up. Nobody has suggested that.

The offset optimization that the OP proposed is trivial to implement correctly even without bound checks (just put an assert on the methods that take &mut self to ensure that the string doesn't grow beyond that).

You have to correct raw pointers on move and copy.

Offsets remain correct on move and copy.

Moving actually moves things in memory, including the thing those references reference. This means the references now point at the old and now incorrect location. Accessing them would trigger undefined behavior.

Self-referencing is only acceptable, if the struct is guaranteed not to move. Rust does provide a mechanism to provide such a guarantee with std::pin but outside of async code, you probably don't want to be using it.

std::pin: https://doc.rust-lang.org/std/pin/index.html

If you're curious about pinning and have a few hours to spare, https://www.youtube.com/watch?v=DkMwYxfSYNQ is a great video that explains it in detail.

  fn main() {
      // ok
      let mut inp = Input { words: vec![], phrase: String::from("foo bar") };
      inp.words.push(&inp.phrase[0..3]);
      inp.words.push(&inp.phrase[4..7]);
      println!("{:?}", inp);

      // this would give "cannot move out of `inp` because it is borrowed"
      //let x = inp;
  }

If it was post Rust 1.0 then it did not. The more likely case is the combination of NLL and match ergonomics, which has made a lot of code way more comfortable, respectively by relaxing local borrows and avoiding a lot of minutia in pattern matches.

For anyone who’s interested:

In Rust, you tend to do a lot of pattern matching and destructuring. But you also often only have a reference to your data, because copies can be expensive.

Combining pattern matching and references was always possible, but confusing: you had to place lots of “ref” annotations in various places, which I never got right on the first try. But now, you can magically destructure e.g. a reference to a tuple into a tuple of references. You don’t have to think about it, it simply works. Combined with Rust’s algebraic types, this allows you to write very elegant, almost fp-like code that’s also zero copy.

I was trying to figure out references and deref, and I kept thinking I "got it" and trying to make sure by writing examples that should and shouldn't work.

However, because of all the deref "ergonomics" magically spread around thinks like match, it was really hard to confirm whether I had the right mental model or not. Lots of things that surely shouldn't work somehow worked, and I couldn't explain why. I kept having to go to forums and people just told me "oh, this is a special magic case we added". Very frustrating.

I remain of two minds about it.

If you want to make sure you have the right model you can always set edition to 2015 tho. You will also lose NLL and a bunch of other conveniences, but match ergonomics will be disabled.

That's a really interesting idea. I wonder if that would work well for teaching languages in general. Like teaching Java 1 instead of 16 where the language was much simpler.

Out of curiosity, since I expect to give a short Rust introduction in the near future, what was your language background when learning Rust? How familiar were you with C-style pointers and/or C++-style references?

    let foo: () = complex_thingy();

I have a background in lots of high level languages, like Python and Haskell, but never thought too much about how the types were represented.

But prior to learning Rust I spent some time writing C (I've never done C++), so I guess I came in with a simple idea of how pointers work.

  #[derive(Debug)]
  struct Input<'a>{
      words: Vec<&'a str>,
      phrase: &'a str,
  }

  fn main() {
    let s="foo bar baz";
    let input = Input {
        words: s.split_whitespace().collect(),
        phrase: s,
    };
    dbg!(input);
  }

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 1.15s
     Running `target/debug/playground`
  [src/main.rs:13] input = Input {
    words: [
        "foo",
        "bar",
        "baz",
    ],
    phrase: "foo bar baz",
  }

For it to be self-referential, Input needs to take ownership of the string in phrase, and words needs to then be referencing phrase.

You can do this with Pin, but it’s not simple.

With Pin:

  use std::pin::Pin;
  use std::marker::PhantomPinned;

  #[derive(Debug)]
  struct Input<'a>{
      words: Vec<&'a str>,
      phrase: Box<str>,
      _marker: PhantomPinned,
  }

  fn test<'a>(s: String) -> Pin<Box<Input <'a>>> {
    let bs = s.into_boxed_str();

    let mut input = Box::pin( Input {
        phrase: bs,
        words: Vec::new(),
        _marker: PhantomPinned,
    });

    unsafe { 
        let phrase: *const Box<str> = &input.as_ref().phrase; 
        let words = phrase.as_ref().unwrap().split_whitespace().collect();
        input.as_mut().get_unchecked_mut().words = words;
    }

    input
  }

  fn main() {
    let s="foo bar baz".to_string();
    dbg!(test(s));
    
  }

The responses you’ve received aren’t particularly kind and as a rust user, I’m sorry for that.

It’s entirely fair to say you don’t understand why it’s not possible to have self referential structs, because it is possible;

If you have raw pointers you can have self referential types... so why not refs?

The issue here is that, like references passed to closures, the type checker isn’t sophisticated enough to track the references and ensure things are correct.

You could very plausibly have a struct in the form described above where moving ‘phrase’ is forbidden until the vec is cleared.

You can literally do that inside a function.

So... the problem here is the rust compiler, and that it’s difficult to implement.

Those who go down that path will experience the same disillusionment we did, and end up with applications that end up costing so much more to maintain if only because of the cost of the maintainers they require. Software costs work better when low-level and high-level programming are kept separate. The former is costlier but tends to be both smaller in size and in prevalence, while the latter is the opposite.

Of course, the number of people who make that mistake of mixing high- and low-level programming won't be nearly as high now as it was back then -- many of us have learned our lesson -- but it would still be interesting to watch this unfold again, even at a small scale. And, thirty years from now, some will be telling us why, while using Rust for high-level programming was indeed, a costly mistake, Muju is completely different, and this time a low-level language really and truly is appropriate for application programming.

Time is a flat circle.

Actually rust is a grate language for programmers of the less capable end of the spectrum.

While it allows clever abstractions it generally discouraged and recommended to write simple code.

The borrow checker might seem like a clever abstraction, but it's just a build in code analytics tool you should use anyway when using C or C++ or well any language, and it generally nudges you to better structured code.

> Then, as now, they were people who hadn't had much contact with the average software developer and with the realities of software mass-production.

Except that more than just a few decisions in the rust design process where strongly influenced by the feedback of average developers, including people which just got started with programming.

Wrt. C++ I can completely agree, it's a completely over engineered language with endless gotchas with silently sneak into you code without you noticing and potentially causing UB if compiled with some compiler in some optimization levels for some target. Making such bugs completely bonkers to track down.

On the other hand in (safe) rust many of the problems user have come from the language helping you to not run into any of this and other bugs.

And all "hidden" complexity rust has is normally designed in a way so that you don't need to know it to use rust or even things related to it as long as you don't want to create some low level primitives which involve unsafe code.

Personally, being a Rust enthusiast, I think that Rust's benefits don't just unleash when you think about performance, but also when you think about large codebases. Such codebases are usually the scene for refactorings. In a dynamic language like js, these are extremely hard to pull off. In Rust, the compiler won't stop yelling at you until you have cleanly finished the refactor. I love refactoring Rust codebases, even ones I didn't write, while in C++ or other languages it's extremely annoying.

And note that while C++ enthusiasts might have believed that everything should be C++, not everyone followed them. Many people still stayed with C. Many still do even with Rust around. But there is a small group of people for whom Rust is such a great improvement that they take the portability cost and switch to Rust. Linus is heavily anti C++ for example, but he's open to adding Rust to the kernel.

Neither Facebook, nor Instagram or Slack are primarily built on C++ or Rust though. And many other products that I can't as confidently remember from the top of my head aren't.

Only later did they introduce Hack and HHVM, which compiles a PHP dialect in a just in time fashion. My point is that once you reach scale, and your computer bill becomes significant enough, you'll really want to use efficient languages.

Now it's Rust based on what? Uber backend is almost entirely built in Go. And so are many other services handling billion plus requests a day written in other languages.

Perhaps Rust advocates know something that Uber engineering does not.

And for the record, when Uber got started Go wasn't available either.

What's a better general-purpose language for this mythical "average" developer? Java/C#? Rust has the same level of memory safety, and adds data-race safety that these languages do not have out of the box. Go is in the exact same boat, btw - memory safe for sequential code, but concurrent code is tricky since unsafe shared access is ubiquitous in real-world Go code. Haskell, Agda and Idris could provide more safety but are not approachable to the "average" dev.

You (rightly, I think) place Idris (and Agda, although that's more a proof assistant than a PL) beyond the reach of the average developer, and also, apparently, Haskell -- arguably a simpler language than Rust, but never mind -- but not Rust. And that's my point and, I guess, our point of disagreement. If you think that, on that spectrum between, say, Python and Idris, Rust is at a good level for the average application developer to the point where maintaining high-level applications written in Rust would ever be cost effective, then I think you are out of touch with the realities of the software industry and the economic forces that shape it. I thought the exact same thing as you twenty five years ago: C++ was obviously the right language for the average developer -- even more so than, I don't know, Delphi or Visual Basic -- wasn't it?

> What's a better general-purpose language for this mythical "average" developer?

I don't believe any low-level language will be cost-effective for application development for the foreseeable future, if ever, and the average developer is anything but mythical (I mean, embodied as a single person, perhaps, but I'm talking about teams).

> Rust has the same level of memory safety

It doesn't (due to much more prevalent reliance on unsafe as well as FFI), but that's very much beside the point because, as you acknowledge, safety is not what it's about.

From a PL research point of view maybe.

But from a POV of what is simpler to use for a average or new programmer, Haskell is far worse as far as I can tell.

> due to much more prevalent reliance on unsafe as well as FFI

Where? In embedded programming? Or programming from primitives (which I would argue a average programmer never should do, there are existing libraries)?

In some use-cases you always end up with a FFI, but that is also true for other languages.

Besides that usage of unsafe is both strongly discouraged and uncommon.

There are a lot of rust use cases where using unsafe code is never necessary to a point where people simple ban any direct usage of unsafe code in their project.

Mr Pressler, would you mind reminding everyone how old you were “25 years ago” to put this statement into perspective?

Could you please stop pretending you're some old hat who's seen this before in 90s or even 80s[1], and trying to give your wisdom to the young generation, this is ridiculous.

[1]: in your initial comment in this thread : > we went through with C++ in the late '80s and early '90s,

As a bonus I can pull in serde with one line and use it without worrying about shooting myself in the foot.

(See for example the "Empowerment, empowerment everywhere" RustConf 2020 keynote.)

If anything Lisp current adoption proves that aiming to tackle both ends of the spectrum in a single language might not be a good idea.

https://en.wikipedia.org/wiki/Rule_of_least_power

Also, Lisp is the most powerful at constructing programs but that means it's the least powerful in the field of making sure your program actually does what you wanted it to - that's what types, borrow checking, proof assistants and so on are for.

(Some people think Lisp is declarative because it's homoiconic but that's not true - you can't find out what a Lisp macro does without executing it.)

But somehow, Rust got cool, and now a large fraction of its community wants to use it to write web services. So there's a lot of gravity dragging the ecosystem, and even the standard library and the language, in that direction. Even though it is a poor choice for almost all web services.

One day, the shine will wear off, and it will be easy to see that it's a poor choice for almost all web services, and we will feel some regret over the amount of time and energy that went into building in that direction.

[1] https://news.ycombinator.com/item?id=27120689

For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/

Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.

Most devops don't use Go and I argue that for the ones who do, Rust is a big improvement. Sure Go is being used to make Docker and k8s, but with this reasoning Haskell is also irreplaceable since Pandoc is made with it… Ironically enough, the mere existence of docker negates the main asset of Go in a devops context: statically linked binaries. Without containers, it's a huge selling point, but as soon as you use docker it brings nothing to the table anymore.

> Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort.

Saying so reveals that you've probably never tried it. The biggest performance issues I've been facing where memory allocations. With Go, things are “magically” allocated or not depending on the compiler's mood of the day (or the compiler version in practice) and you need to diagnoses these by looking through the escape analysis log, see when the compiler cannot elide the allocation and refactor until it works. With Rust, you just don't allocate memory unless you're using a `Box` or heap-allocated collection (a Vec or a HashMap for instance).

In both case you can have an implementation with a good performance, but with Go you need tedious tuning, while Rust gives you an explicit control of the allocations. That's an enormous productivity difference.

Time will tell. I used to think this way, but don't anymore.

That doesn't mean it's right for the majority of them, but I think it's workable for a very surprising number of them.

A lot of things that are hand waved away in C++ (who owns this? How long does this need to be alive? Can I mutate this?) are completely explicit in a Rust interface. And Rust's type system is strong enough to express a lot of rules that no one would want to write down in C++ (because overriding them is just one cast away), allowing us to write hard-to-misuse libraries.

Coding on top of such libraries is a really fun experience. That's why I call Rust an all level language.

is it a good or a bad thing?

Seems like I should make a Rust article just for it to soar to HN's frontpage, just for developer marketing of my product that is unrelated to Rust.

Bravo.

It was fun, but our conversion rate from the blog was zero. Maybe there was some downstream brand recognition effects, but we treated it like a fun thing for developers to do to share some knowledge.

The only real downside was that a couple people got hooked on the idea of using the blog for thinly veiled self-promotion, so it required some clear expectation setting. It worked best when posts were treated as group efforts by the team instead of individuals posting to the company blog with everyone else as silent editors.

Rust posts have gotten excessive of course, but that's different.

This takes 50 LOC, gives you a doubly-linked list that's memory safe, thread safe, and that has pretty much the same efficiency as a doubly-linked list using raw pointers. (Feel free to prove me wrong here, but I've written one, and I couldn't measure the difference on x86, i'd expect ARM to be even better because it has weaker atomics).

Compared with a Vec<T> or a HashMap<T>, what dominates the performance of a doubly-linked list is the pointer indirection to access the object, and the cost of that is pretty much the same whether you are using Arc<T>/Rc<T> or a raw pointer.

Also, a doubly linked list only makes much sense for relatively large objects and when you want O(1) splice, so whether you store 64-bit or 128-bit wide pointers doesn't matter at all, because the objects are big, and O(1) splice just modifies 4 pointers...

You pick the linked list because of better scalability as the data size grows bigger, you choose them precisely because you think the constant overhead vs contiguous lists is worth it.

The most common example is an object that wants to remove itself from a big list.

E.g. you have a OS with 10000 processes. 1000 processes die per second and they already know their position in the linked list so they remove themselves in O(1). An array would require leaving the slot empty and swapping in the last element (unordered list) O(1) or shifting entries to fill the gap (ordered list) O(n). The former breaks ordering, the latter leads to O(nm) removal costs where n is the number of live processes and m the number of dying processes. Paying reference counting costs is not a problem.

FWIW the original suggestion mentioned tombstoning so you'd have a Vec<Option<T>> instead of a `Vec<T>`, and "removing" an item would just set the `Option` to `None`.

Of course this would increase iteration cost (as you'd have to skip the `None`), and you'd probably want to compact the vec once in a while.

I have a question for you, would you say that the increase of difficulties with doubly linked lists are incidental in nature, or is there something inherent with doubly linked lists that impact security? Like I said, I like the doubly linked lists for certain things, and the more I know about the impact of using them the better!

I certainly will be reading up on this!

Or a custom Vec that has a lower maximum bound, at which point you can start doing things like integer encoding/ pointer swizzling.

It takes almost no time at all to do that, depending on the size of the elements. But you have a starting assumption there that the vector must always be stored sorted. Challenge that assumption. If insertion is perfectly balanced with traversal it may be true, but that's also rarely the case. It's fairly trivial to instead track if the vector is already sorted or not & sort when sorted access is actually needed.

> Besides, linked lists aren't that bad if the nodes are close enough in memory (read: consecutive)

Which doesn't really happen outside of a controlled benchmark. If the linked list is stored in a single consecutive allocation, then resizing has observable side effects (eg, pointers to elements become invalidated). You can do things like allocate chunks at a time so that some elements are consecutive, but you won't have all elements consecutive or close in memory.

> It takes almost no time at all to do that,

Uh, 500 loads and dependent stores, at minimum, in the best case hitting L1 cache, which is 3 cycles. So you are talking about 1500 cycles to....avoid a single cache line miss due to chasing a linked list pointer? A miss to main memory is 100-200 cycles, maximum. More likely you are going to L2/L1 which is 12-50 cycles. So no, in no circumstances would I expect copying 500 elements to be faster than chasing a single pointer.

> Challenge that assumption.

You don't get to pick the application behavior. If it needs to a do a lot of inserts and traversals, it just does.

>> are close enough in memory (read: consecutive)

> Which doesn't really happen outside of a controlled benchmark.

There is no supporting information for this statement at all. Of course a list created all at once using a bump-pointer allocator is going to be consecutive. And a (moving) garbage collector is going to dynamically reorganize the nodes of a list, generally in a breadth-first way, depending on the marking algorithm. That can result in the nodes of the list being laid out consecutively after compacting, no matter where they were originally organized.

Memory behavior of programs is complicated. I find it surprising that we're having a conversation that we can't or shouldn't use linked lists now because vectors are universally better, or we can lazy sort or some other crazy workaround. I'm not sure what motivates this whole line of argumentation. Sometimes lists are just the best damn thing.

This is absolutely not how modern CPUs work, and I think you misunderstood where the dependencies are. All the load/store pairs are independent from each other, which means they can be executed in parallel. Which means that this code is throughput limited. Modern CPUs tend to have at least 2 load/store ports, so we're talking a throughout of one copy per cycle, or 500 cycles for the entire operation (plus warm-up time).

Furthermore, this is a pure memmove in many cases, which means a real memmove implementation that has been optimised using vector instructions can be used. Now you're talking about moving 32 bytes per cycle, or 4 array entries if they're pointer-sized, which brings us down to 125 cycles plus warm-up. Which is on the order of a miss to memory...

And oops, now your vectors are 1 million entries.

I appreciate the discussion. It's a bit of a rathole for something that you shouldn't be optimizing if you can completely avoid it by using the right data structure for your needs.

As soon as you traverse that linked list of 1 million entries, oops.

In fact, here, I put together a quick benchmark. It inserts in the middle of the list and then traverses it (since, after all, ordering is irrelevant if there's no traversal).

https://paste.ofcode.org/7Buz2Mua9xna55TC3uFaQp

Test system is a Ryzen 3700x. I tried to avoid all amounts of compiler optimizations and believe I succeeded, but by all means happy to take a review of the above. Would love to see you do a similar test in whatever runtime you want, especially one with that juicy super-amazing compacting GC that makes linked-lists so fast.

At 100 elements vector wins (40ns vs 160ns). At 1000 elements vector wins (~300ns vs. ~1000ns). At 10,000 elements vector wins (~2700ns vs. 12,000ns). At 100,000 elements guess what? Vector still wins (29us vs. 130us).

You are either vastly underestimating how slow linked-list traversal is or vastly overestimating how expensive memmove is.

But you did say 1 million entries so let's give that a shot:

    Vector size 1000000  took 286,123ns

    Linked-list size 1000000  took 2,670,542ns

And this is the basically best case for linked lists of inserting in the middle happens equally as often as traversal, I'll point out. If traversal is rare obviously a lazy sort would crush these vector results, and if traversal is common the linked lists results get that much worse.

Now really these results shouldn't actually be that surprising if you really dig into it. After all, the vector version of this is storing (and therefore traversing) 4MB of data. That's all 1 million ints really is, it's not very big. Now sure you can store bigger things, but much bigger and you're probably storing a vector of pointers instead which only bumps that to 8MB of data. The linked list version, on the other hand, is storing 2 pointers + an int for each node. That's 20MB of data total. So resizing the vector involves a read of 2MB of data, a write of 2MB of data, and a traversal of 4MB of data - 8MB total. Simply traversing the linked list is hitting 20MB of data - over double the amount of memory bandwidth utilized. That's a big difference. In fact on my system at 1 million entries that happened to be the difference between the vector version comfortably fitting in L3 with loads of room to spare (especially since the resize made part of it nice & hot) vs. the linked-list version not coming close to fitting (specs on this CPU claim 32MB of L3, but it's really 16MBx2 - hitting the far L3 isn't much slower than hitting main memory). So more data to hit and it's pointer chasing? Modern CPUs just really hate that. Like a lot.

Since I don't intend to cheat at happening to have sufficient L3 for the use case you laid out (combined with the benchmark naturally keeping this hot), I also tried adjusting it. I changed the containers to hold intptr's instead, and hit it with 10 million entries. Neither one comes close to fitting in L3 now. Still 80MB of data for the vector vs. 240MB for the linked list but maybe not having that copy and with both of them thrashing L3 the linked list might finally show something to redeem it.

    Vector size 10,000,000  took 3,680,111ns
    Linked-list size 10,000,000  took 26,460,333ns

> I appreciate the discussion. It's a bit of a rathole for something that you shouldn't be optimizing if you can completely avoid it by using the right data structure for your needs.

And a linked list is rarely the right data structure, so yes you should avoid trying to optimize for that without measuring.

My guess is that the linked list impl remains almost the same while vec sees a linear ish slowdown.

However, with bigger data in my experience a very good solution is often to have a vector of pointers to the actual data. This loses some locality of course, but during traversal the fact that you don't have dependencies between iterations can still be a win.

But since you asked I adjusted the benchmark to instead contain a 100byte & 1kb payload (just an array of ints). And in the loop I just use the first number of the array in the summation. I assumed an iteration isn't accessing the entire payload but say instead an ID or whatever.

I also added a vector that is pointers to the data instead of the data itself (always a new allocation, none of the pointers are the same)

For 100 bytes:

    Vector; payload sizeof=100 of count 100 took 142ns
    Vector-of-pointers; payload sizeof=8 of count 100 took 150ns
    Linked-list; payload sizeof=100 of count 100 took 180ns
    
    Vector; payload sizeof=100 of count 10,000 took 18,796ns
    Vector-of-pointers; payload sizeof=8 of count 10,000 took 8,670ns
    Linked-list; payload sizeof=100 of count 10,000 took 32,853ns

For 1kb Results:

    Vector; payload sizeof=1000 of count 100 took 1137ns
    Vector-of-pointers; payload sizeof=8 of count 100 took 549ns
    Linked-list; payload sizeof=1000 of count 100 took 387ns
    
    Vector; payload sizeof=1000 of count 10,000 took 120,709ns
    Vector-of-pointers; payload sizeof=8 of count 10,000 took 10,681ns
    Linked-list; payload sizeof=1000 of count 10,000 took 105,927ns

Think about it like this: Traversal speeds of linked lists are bottlenecked by memory latency. Traversal speeds of vectors are bottlenecked by memory bandwidth. Only one of those metrics has been improving over the years.

Code: https://paste.ofcode.org/hYTf6PYPJegWLReSGQyUBg

One use case where I think linked lists would be far superior would be merging two sorted linked lists. That can be done completely in-place with a linked list, consuming no intermediate memory. With vectors, you end up with an intermediate copy, either of one of the lists, or both. If you take the result of merging two lists, then merge it with a third list, then take that and merge it with a fourth list, etc, you can't really do this with a vector-of-lists representation that might come to mind.

Benchmark it & prove it. I expect you're still vastly underestimating how slow it is to traverse a linked list.

To visit a node in a linked list you must first load the node before it. Every iteration is a dependent load. You get no pipelining here, so every node lookup is ~100ns. Meanwhile for vectors each index is independent, so they are nice & pipelined. Yeah you're copying, but you've got vastly more memory bandwidth than memory latency.

Also to zipper merge 2 linked lists means updating 2 * N pointers. That's essentially a copy of the entire list right there, depending on the size of the contained object.

For context: A cold memory fetch is ~200 cycles. That's around 10 incorrectly-predicted branches. That's around 100 correctly-predicted branches. You need to be skipping a lot of work to justify injecting 100s of cycles of lag inside a loop of some sort.

(And, of course, those situations would need to be the common, relevant case. Don't follow a 10x performance speed-up in a one-off situation at a time no-one cares about to justify a 5x slowdown in a critical, hot loop.)

If you have big objects, then this might also start to become a concern. However, in those cases, a vector of pointers (or structs of pointers + metadata) would appear as a new challenger. In that case, you would only take the latency hit if you actually need to go to the object (and those objects could be held in contiguous storage, etc. etc. etc.).

Chances are that, unless you have data for your specific case showing otherwise, vector will probably win. It should be the default unless you have a reason not to, and evidence to back it up.

One of my quick warm-up questions is asking about what data structure to choose if inserting an element after an element you already have a reference to is a common operation that you want to optimize for.

Of course, I don't consider there to be a right or wrong answer, but just make sure that people can intelligently discuss it. Some people start off with vec or the like, and then we discuss how fast that would be compared to a linked list. I generally stop after we get to the O(n) vs. O(1) comparison.

But maybe if we have some extra time I should also talk about the tradeoff with actually traversing the list.

After all, I suppose this is why things like gap buffers are popular for text editors, rather than linked lists.

No I'm talking about 1500 cycles to avoid 1000 cache line misses. Ordering only matters if you're traversing, and traversing a linked list sure as shit isn't a single cache line miss as I'm sure you know.

> And a (moving) garbage collector is going to dynamically reorganize the nodes of a list, generally in a breadth-first way, depending on the marking algorithm.

We're talking about Rust & C++. There isn't a moving GC.

> You don't get to pick the application behavior. If it needs to a do a lot of inserts and traversals, it just does.

If it's doing that linked lists perform terribly. Traversals of linked lists that suddenly become a million long are insanely slow. That's dependent loads and cache misses all the way through. And even if your hypothetical GC works flawlessly giving you maximum compactness, you're still blowing likely half your throughput & cache size on pointers to neighboring nodes. Even more if it's a doubly-linked list.

> Sometimes lists are just the best damn thing.

It's potentially possible, sure, as I even acknowledged but you seem to have skipped. No, the argument is that they are rarely the right thing, so the focus on them being difficult in Rust is irrelevant.

If you actually know doubly linked lists are what you need then Rusty's unsafe is almost certainly not a deterrent.

A modern CPU has 200Gb/s of bandwidth. If the objects in your array are 200 Gb in size each, then swapping the position of two elements in a vector is going to take O(seconds) at memcpy speeds, while doing this with a linked list is going to take ~1 * 10^(-11) seconds.

That's a performance difference of 11 orders of magnitude...

You can make the objects in the array smaller (e.g. 200Mb each instead of 200Gb each) and your two-element swap would still be 10^8 times faster with a doubly linked list.

---

In the parallel threads, people seem to just be arguing that a vector is always faster than a list, without understanding "why" this is the case, and making claims about "what the hardware does" without doing basic rule-of-thumb calculations to verify their claims.

Not necessarily. If those items are aligned to a memory-page boundary, memcpy will probably do a page table update instead of actually moving the values in RAM.

This is where Big-O just really doesn't have a strong relationship with performance. Iterating over a linked-list is O(N), same as a vec. But in the real world it's nowhere close to as fast.

So then if you're not regularly iterating over it a bag implemented with a vec is likely a better option. Then just have a bool that tracks if it's sorted or not, and in the (relatively) rare case you need sorted traversal just sort() it first.

The whole construction ends up extremely efficient in practice for this kind of thing, since you get log(n) indexed lookup and log(n) insert time. I don’t know why they aren’t used more.

You can do what you describe without the tree by also having your linked list instead contain small arrays of items instead of individual items, but you then lose the property that you can stably point at an item in the list across inserts. And both then suffer from the problem that finding the element to remove (or insert at) is no longer O(1) as a result. Not as bad on the tree, of course, but you're into the realm of you really need to benchmark a specific implementation of the idea & outline the specific constraints to see if it really beats just the good ol' vector and/or hashmap.

They wouldn't be used so heavily in filesystems and databases if they were slow to iterate through.

[1] https://en.wikipedia.org/wiki/B%2B_tree

Iterating through a b-tree with a large branching factor (and multiple items at each leaf) is significantly faster than iterating through a linked list in practice, because main memory lookups dominate the linked list performance. With a b-tree you only need to do a main memory read after iterating every ~100 items (or whatever the leaf size is). With a linked list as you're describing you need to do it every item. Inserting is still O(1) - the branch size at each leaf is a constant factor. And its a small constant factor (memcpy is faster than you think it is.)

You can make linked lists fast for arbitrary insertions by storing forward pointers that skip more than 1 element, and by storing multiple elements at each leaf. If you do you end up with a skip list - which is a data structure with basically the same performance characteristics as a b-tree but a bit less performance stability.

Linked lists with a single item per node are basically never the appropriate data structure to use for any application. The only time I've seen them used in a sensible way was through clever use of intrusive lists in a physics engine, to avoid allocations & smooth out any spikes in allocator load from reallocating vectors. Even then the justification was bit dubious. Oh, and I've seen them used in JS where its much harder to implement high performance, complex data structures.

Anyway, I highly recommend anyone who's interested actually benchmark some different scenarios. Its remarkable how much of a difference good data structures make. The big insights I've had are that memcpy is way faster than I think it should be, and memory reads are way slower than I think. Vectors do perform well in practice, even with arbitrary inserts because of how fast memcpy is. But that gets beaten out by well written b-trees if you're doing inserting at arbitrary positions quite quickly (usually around when you have about 10k items in my experience).

I want to like Rust, if only because anything has to be better than C++. C++ is godawful and it sucks that all these decades later it’s what serious big software is written in.

But I haven’t found the explanation of Rust and it’s trade offs and philosophy written by someone who can write serious Haskell and Lisp and C++ and is like “Rust. This is the way. Here’s how and why.”

I’m sure there are much better blog posts than this one that shed light on how parametric as opposed to ad-hoc polymorphism is natural in Rust with no runtime cost. Or how Rust’s nested angle-bracket hell to get a pointer to a piece of memory is actually a deep and profound algebra that exposes std::move for the fraud it actually is or whatever.

Where do I find the explanation of why Rust is less awful than C++ written by someone who has written a lot of C++ out of necessity, doesn’t take non-browser JS seriously, doesn’t think 8 boxes need kube, doesn’t stand to make consulting revenue off having been involved in Cargo, and generally uses C++/Python because they’ve got work to do?

Where do I go to see the light as someone who has some idea how brilliant Eich is and also knows how ridiculous it is to use JavaScript when you’ve got an alternative better than Lua? (I’ve written a JavaScript compiler, I know how unfortunate node.js and Electron are).

I want to be sold! Sell me!

https://youtu.be/Gv2I7qTux7g

C but with the problems fixed.

The only limitation that may not eventually be removed is the lack of dependent types (although you can kind of emulate them by lifting terms to the type level and using lifetimes to represent variables).

C++ is not memory safe, Lisp has no type system and Haskell has GC, all values are boxed in a closure and it cannot mutate memory safely, so none of these languages are even in contention.

I’m not being sarcastic, in all earnestness educate me!

vector<int> v{1,2,3,4}; for (auto&& i: v) v.push_back(i);

Again, in the spirit of becoming more educated, what's the equivalent Rust code? I have `rustc`/`rustup` on my box so I can run that too.

It gives you a small example of what the error is, explains it, and tells you how to fix it.

This is a very nice feature for new people (like myself).

In C++ you (usually) do this with `const`, which is fairly low friction, very statically analyzable, and I'm a little unclear what bug hardcore borrow-checker static stops me or my colleagues from making that `const` can't catch?

Rust catches the bug where you forget to use `const`, because the C++ compiler doesn't force you to use it. Your argument boils down to "I don't need Rust's borrow checker, I just have to remember to use a dozen tricks, follow various patterns and guidelines, run several static analyzers and runtime checks, and I'm almost there".

This is not meant as an attack against you. I used to program in C++, and I'm mostly using Rust now. The borrow checker frees up those brain resources which had to keep all those tricks, patterns, and guidelines in mind.

But to directly answer your question, suppose I have a “struct FloatArrayView { float* data; size_t size; };” Of course this is a toy example, but humor me for now and consider the following:

1. Without excessive custom effort (e.g. without manually unwrapping/wrapping the internal pointer), how do I pass it to a function in C++ such that the data pointer within becomes const from the perspective of that function (i.e. you’ll get a compile error if you try to write to it?) Hint: It’s very complex to do this in C++, vs trivially easy in Rust. And no, passing as const or const reference to “FloatArrayView” does NOT work. The only solution in C++ for complex composite types operating with “by-reference semantics” is ugly, complex, and horribly error prone to maintain correctly. For a more concrete example, consider how “unique_ptr” works with the constness of the value it holds. A “const unique_ptr<T>” is NOT a unique pointer to const T. A “unique_ptr<const T>” is, but the relationship and safe conversions between these are not simple or easy to implement or even use in many cases. It gets even worse when you need to implement a “reference semantics” type like this that is inappropriate to be a templated type, or contains a variety of internal references unrelated to the template arguments.

2. Now suppose I solve #1 and pass this into some class method, which then stores a copy of the const reference for later. But I as the caller have no way of knowing this. So after that method returns, I later proceed to modify the data via my non-const reference (which is a completely valid operation), but this violates the previous method’s assumption that the data was immutable (will never change). This creates an incredibly dangerous situation where later reads from that stored const reference to data (that was assumed to be immutable) is actually going to actually yield unpredictably changing results. Const is not immutable. Question: How do you make it so C++ guarantees that passed reference is truly immutable and will never be mutated so long as the reference exists, and enforce this guarantee at compile time? In Rust this is easy (in fact, it’s the default). In C++, it is impossible. The closest you can get in C++ are runtime checks, but that’s nowhere near as good as compile time checks.

Edit: Removed a bunch of perhaps unnecessary extra C++ trivia which I’ll save for later :)

To be more clear, in Rust, the `mut` you see in bindings (like `let mut blah = ...`) is wildly different from the `mut` in `&mut T`. There was discussion on whether the latter should be renamed to `uniq` (because `mut` is misleading). In any event, Rust lacks `const` types. There is no `const T` like in C++. So something like this is impossible,

  std::vector<const int> vec;

Secondly, a value of a type `&T` can be mutated internally (aka interior mutability). A function taking a `&T` type and mutating it behind the scenes is very whacky. AFAII, interior mutability exists only to trick the borrow checker using the `*Cell` types (which use unsafe internally BTW).

Imagine all the best tools and all the best and memory safe features all rolled up to one called Rust.

Lastly, with C++ there are many situations where the memory unsafe actions are not caught until they are triggered dynamically. So like others have mentioned, you’d have to have the best test suite combined with the best of fuzzing etc.

Or you can just use Rust where nearly everything is caught at compile time with useful errors and when something funky does happen at runtime it will just panic before you cross into UB/ unsafe land

If this doesn't seem like a game changer to you, then you probably don't grok its scope and impact. I don't really know how to give that to you either in HN comments. I think you maybe need a synchronous dialogue with someone.

Assuming the absence of `const_cast`, C++'s `const` ensures that a data of the particular type doesn't get modified. That's it. Rust on the other hand, tracks and restricts aliasing. This means you can't get both a constant and non-constant reference to an object or anything owned by it (more precisely anything transitively reachable from it). This is helpful in preventing issues with invalid pointers (like iterator invalidation). For instance, if you have already borrowed an iterator (which is essentially a reference) you can't issue mutable operations on the vector (issuing mutable operations entails a mutable borrow), and that could potentially reallocate the backing memory of the vector. This property is also useful for preventing multiple writes to the same location in a multi-threaded application, making programs adhere to the single-writer principle by-construction.

The downsides are that you might sometimes need to contort your code or your program architecture or perform mental/type gymnastics to write some trivially safe code or even use unsafe (or else lose performance) to satisfy the borrow checker.

   #include <vector>
   int main()
   {
     std::vector<int> foo{1,2,3,4,5};
     foo.reserve(foo.size()* 2);
     for(auto it = foo.begin(), end = foo.end(); it < end; ++it)
       foo.push_back(*it);
   }

    fn main() {
        let mut v = vec![1, 2, 3, 4, 5];
        let new_size = v.len()*2;
        v = v.into_iter().cycle().take(new_size).collect();
    
        println!("{:?}", v);
    }

- Repeating the vector using the built-in method `Vec::repeat`. This allocates a new vector, but `reserve` is likely to do the same, just implicitly.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

- Using a traditional for loop. There are no lifetime issues, because a new reference is acquired on each iteration. The reserve is not required, but I included it to match your C++ version. https://play.rust-lang.org/?version=stable&mode=debug&editio...

- Creating an array of slices and then concatenating them into a new Vec using the concat method on slices: https://play.rust-lang.org/?version=stable&mode=debug&editio...

    #include <vector>

    void do_stuff(int &a, int &b) {
      // stuff
    }

    int main() {
      int my_array[2] = {42, 99};
      do_stuff(my_array[0], my_array[1]);
    }

    fn main() {
        let mut my_array = [42, 99];
        do_stuff(&mut my_array[0], &mut my_array[1]);
    }

    error[E0499]: cannot borrow `my_array[_]` as mutable more than once at a time
     --> src/main.rs:7:32
      |                                                                 
    7 |     do_stuff(&mut my_array[0], &mut my_array[1]);
      |     -------- ----------------  ^^^^^^^^^^^^^^^^ second mutable borrow occurs here
      |     |        |
      |     |        first mutable borrow occurs here
      |     first borrow later used by call
      |
      = help: consider using `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices

Getting multiple mutable references into a single container is tricky in Rust, because you (usually) have to statically guarantee that they don't alias, and how to do that depends on what container you're using. The suggestion in the error message is correct here, and `split_at_mut` is one of our options. Using it would look like this:

    fn main() {
        let mut my_array = [42, 99];
        let (first_slice, second_slice) = my_array.split_at_mut(1);
        do_stuff(&mut first_slice[0], &mut second_slice[0]);
    }

At a high level, Rust's attitude towards multiple-mutable-references situations is leaning in the direction of "don't do that". There are definitely ways to do it (assuming what you're doing is in fact sound, and you're not actually trying to break the aliasing rule), but many of those ways are advanced and/or not-zero-cost, and in extremis it can require unsafe code. Life in Rust is a lot easier when you refactor things to avoid needing to do this, for example with an entity-component-system sort of architecture.

And that doesn't work, because the v.iter() is sugar for Vec::iter(&v), while the v.push(i) is sugar for Vec::push(&mut v, i) . I think it'd use deref coercion on the i, as Vec::iter(&v) gives you `i: &isize`. If this wasn't ints (or other `Copy` types, for that matter), you'd need to use .into_iter() to consume the Vec and get ownership of the entries while iterating, or use `.push(i.clone())` because `Vec<T>::push(&mut self, T)` is the signature, and you can only go automatically from `&T` to `T` for `Copy` types. Actually, it _may_ even need `v.push(*i)`, thinking about it. Try on https://play.rust-lang.org

C++ is actually a pretty gradually-typed language, and I'm in general a fan of gradual typing. I don't mind that some people prefer BDSM-style typing, but IMHO that goes with GC e.g. Haskell a lot better than it does with trying to print something out or copy it or whatever.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Alternatively, you can loop over indices instead of values, which doesn’t require the loop to maintain a reference to `v` across iterations:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Batteries included with safe defaults is a BIG feature.

Legacy C/C++ code is littered with so many memory related bugs that big companies are funding people to rewrite essential unix utils in Rust.

Modern C++ vs. modern Rust. Why is modern Rust better? Legacy C++ can be transformed into modern C++ is a semi-mechanical, semi-you-emply-someone-good-at-emacs way, at a cost in time, money, and risk way less than empty editor.

1) it requires a later execution, rather than your code failing to even compile.

2) it requires excellent and complete tests, probably with quality fuzzing, as often the corner cases (like hiting buffer size limit) is where problems occur.

For me, the argument for Rust is exactly that it let me (mostly) get rid of ASAN and UBSAN and valgrind and friends, which I consider required for C++.

The other big advantage of Rust is package management, with I feel C and C++ are awful at, particularly if you want to release for Linux, Mac and Windows.

I think I consider the need to run under ASAN in a configuration that gets code coverage a feature rather than a bug. It's stupid monkey-brain stuff, but the forcing function of needing to be able to drive your critical path at will in my experience leads to better outcomes.

But since Rust's Memory Safety guarantees apply to components, the composition of those components also has Memory Safety by definition.

If you have one guy writing incredibly scary to-the-metal unsafe Rust to squeeze out 1% more performance from a system that's costing 85% of your company's burn rate, you can put that tiny component through ASAN hell, looking for any possible cracks in its Memory Safety with all sorts of crazy input states.

But the sixteen other people in the team writing stuff like yet-another REST JSON handler entirely in Safe Rust don't need that effort and when you compose all these pieces together to build the actual product, you don't need ASAN again, you checked that the scary bit was safe and you're done.

Also, even if Rust only caught by itself what Clang and half a dozen analyzers would catch, you also get a really nice language as a bonus. There is much more to Rust than just safety.

The by-design thing I get for like something with a port open, but as a default? It's been a few months but the last time I was trying to hack a Rust project printing stuff out hit the borrow checker. I can live without that.

Rust is admittedly a language you can't just jump into without spending some time learning the fundamentals. If you try to do anything non-trivial without grokking the basics of ownership and borrowing you are bound to run into frustrating issues.

But what I actually get is a comparably slow build, a comparably “!$&@>>>>”-heavy syntax, yet another failure to do macros that impress a Lisper in a curly brace language, and now the static analyzer’s usually good advice is mandatory and can’t be turned off to do a quick experiment.

I always have to watch my cynicism because I’m a bit autistic and I offend way more often than I mean to, but if I’ve got 1MM lines of C++, I’ve got a pain in the ass on my hands. If I start porting any meaningful part of that over to Rust, now I’ve got two giant pains in the ass.

Additionally during development a full build is usually not necessary all the time; oftentimes it's just enough to check the code for errors with `cargo check`, which is usually significantly quicker than building a full debug binary.

Edit:

I tested building Alacritty from source on my computer (Ryzen 5600X, Windows 10). The initial build (consisting of 130 crates) took 34 seconds. Building again after adding a single print statement took 6 seconds, and `cargo check` took about half at 3 seconds. It's not ideal by any means, but IMO it's not also unreasonable for 25K lines of code, plus those ~130 dependencies.

Not saying this is true about Rust, but I find these approaches dangerous because they can move bugs off to a different meta level where they're harder to detect.

For instance, some people make safe C dialects where signed integer overflow wraps around or variables are auto initialized to 0. Well, what if you didn't want to overflow at all or 0 was the wrong value? Now you can't find the bug because the program has been redefined to do the wrong thing instead of simply crashing.

Most of Rust's safety features are handled at compile time, and they are usually handled explicitly, not implicitly. A few examples about initialization:

* An instance of a struct is created by giving an initial value to each field. Leaving out any field is a compile error. Since structs are always completely initialized, you can't accidentally pass references to partially initialized structs like you could in a C++ or Java constructor.

* All local variables must be initialized. Accessing a variable before initialization is a compile time error.

* Structs have no implicit default value. The default value can be defined by implementing a trait, either by yourself or by deriving it with a macro (which would default integers to 0 and so on). Default values are only used by a fixed set on functions in the standard library, and never implicitly.

The overflowing case is one of the only cases where Rust is a bit more implicit. Integer overflow is checked at run time in debug builds (so over/underflow causes a panic) and defined to wrap around in release builds. However, the standard library also defines methods on numbers which explicitly use wrapping, saturating or checked (either return a Result value or crash) semantics.

I don't know enough about Rust to comment on whether it does a better job than C++ on reference cycles, but my suspicion is that it does.

[0] https://www.chromium.org/Home/chromium-security/memory-safet...

[1] Related discussion: https://news.ycombinator.com/item?id=26861273

AFAIK avionics software is still largely written in Ada, because it won't let you fuck up meters vs feet type stuff. And if someone said: "Rust has a slam-dunk niche: we're going to crank static analysis past helpful to downright intrusive because sshd simply can't buffer overflow", I'd be like, yeah, ok.

But at the time I stopped using it, Alacritty couldn't handle meta keys on Big Sur, and I wanted to fix that, so I spent a weekend or two that I really couldn't spare trying to unfuck it, but between `print` not being obvious (because someone had already borrowed the thing I wanted to print out) and the build being slower than C++ I timed out.

If they can’t get it right, who can?

My suspicion is that this is too optimistic, but I can't really substantiate it.

What would be a good security-sensitive modern C++ codebase, ideally from a high-profile source like Google, to compare against?

I mean C++ dependency management is so bad there is a concept of a header only library so you just have to copy the file into your project with no support for managing versions.

C++ dependency management is so bad people use the OS installed dependcies because they struggle to set up a build environment otherwise.

What I'm saying is that C++ is pretty good and toe to toe C++ with all the tools you describe and Rust are fairly comparable. But with Rust the whole ecosystem uses it so the network effects make things much better. And it's snowballing.

I actually think this is one of the things that Rust could crush C++ on, because build times are becoming the whole show on big C++ projects.

It's super weird to me that C++, with this whacky 1970s constraint that totally fucks up modularity, still builds neck-and-neck or better with Rust.

In principle Rust could do *way* better on this, and that is a feature that might get me to consider Rust seriously, no matter how stupid I think the borrow checker is. But Rust still compiles dog slow...

[0]: https://github.com/mozilla/sccache

Not so fast! The compilation and linking is neck and neck with Rust so you can have an ELF in the same amount of time. But then you have to run all the C++ tools you mentioned to have parity with what the Rust compiler is doing.

> for all the talk about C++20 modules they haven't delivered yet.

Even when they're delivered, will all the libraries you depend on use them?

>In principle Rust could do way better on this, and that is a feature that might get me to consider Rust seriously, no matter how stupid I think the borrow checker is. But Rust still compiles dog slow...

The team that built the Borrow Checker deserves the Turing Award. It is an outstanding bit of computer science and engineering. I'm surprised that you think it's stupid.

It used to be dog slow but it's gotten very fast in the past two years. Another achievement.

>In principle Rust could do way better on this, and that is a feature that might get me to consider Rust seriously

Modules? Your take away from all this is that modules are the killer feature of Rust and that the Borrow Checker is stupid?

I call shenanigans. You are an elaborate troll. Well done for getting two responses out of me.

On the security standpoint and a wide net of crates.. that's a problem, same as with npm/yarn/pip/whatever and I agree on that. That one bugs me as well. Difficult to audit.

Edit: this post keeps getting up and down voted. I suspects it has to do with the phrase infected by gplv3. I like the license fine, but being realistic many businesses treat it like radioactive waste, so that has to be a consideration

Of course this is not an answer to your comment.

Even if you use std::unique_ptr you can still run into use after free bugs. std::unique_ptr is just heap allocation with a "stack allocation style" lifetime. You can still run into use after free by putting a reference to stack allocated data (this applies to std::unique_ptr as well) into a struct or global variable that outlives the stack allocated data. std::unique_ptr isn't really meant to solve use after free, it exists to ensure that heap allocated data is properly freed eventually. It saves you the discipline to match every new with a free but nothing more.

This is something that you can only solve with a borrow checker. If you were to add the ability to detect these types of problems in C++ then you would have essentially added a borrow checker to C++.

Rust's borrow checker makes it impossible to write code containing a data race. It does this by only accepting a subset of possible safe programs, but this is (or at least may be) a reasonable trade-off due to the guarantee you get.

It's not that you can't write safe code in C++, but you're always at the mercy of your validation to try to have confidence that you've actually managed to do what you set out to do. While Rust obviously doesn't preclude bugs at all, but it does enforce that you _can't_ write a certain class of previously-prevalent bugs.

I think this blog post from Mozilla does a good job of what that means in practice: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...

I think this is correct but would expand on the nature of the tradeoff. Rust only accepts a subset of safe programs, and can express any program in the abstract, but that subset may not contain the optimal safe program. In some cases, differences in practical performance between the expressible safe program and the optimal safe program can be quite large.

Modern C++ cuts a tradeoff along a different dimension: it will accept unsafe rubbish but the optimal safe program is also expressible in virtually all cases. C++ has large niches where it can express optimal safe programs, and where this optimality is important, that Rust cannot. Obviously it is incumbent on the programmer to write safe code in C++, but the flexible type system is more capable of enforcing safety than I think people expect, particularly in recent versions of C++.

But there's optimal and there's "optimal" -- by restricting the developer, we open up more opportunities for the compiler to optimise the code (for all that Rust isn't necessarily able to take advantage of these opportunities yet) and a judicious use of `unsafe` may even help us to build an abstraction that gives us the optimal program anyway. Crucially, code that uses unsafe is still no less safe than ordinary C++ code.

From my days as a compiler engineer, I definitely prefer to write clear code and fix the compiler rather than try to convince the compiler to produce the right result by mangling code. And to build my control logic as an abstraction, even if it's only going to be used in one place, so it can be verified separately from the business logic it drives.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust+data+r...

A quick check suggests that (as would be expected) they're caused by `unsafe` blocks. Specifically, by the developer claiming that a value was safe to send to a different thread while it actually wasn't. One thing to note is that these bugs neutralised the compiler's validation is these specific cases -- allowing, rather than causing, races. Using unsafe means the developer needs to ensure they maintain the invariants themselves within the unsafe block, while in C++ one has to maintain these invariants in _all_ code.

Here's an example from one of Herb Sutter's talks, which I refer to frequently. He describes an issue that can come up with shared_ptr in reentrant/callbacky code, and the punchline is that you have to be careful never to dereference a shared_ptr that might be aliased: https://youtu.be/xnqTKD8uD64?t=1380

I also just wrote a giant example of my own :) in reply to your toplevel comment. https://news.ycombinator.com/item?id=27168368. TSan will be pretty good at catching some of the simple variants of this, like where you totally forget to take a lock. But it's going to have a hard time with cases where you "stash" a reference longer than you should, because later uses of the reference might appear safe for a while yet become unsafe down the road with unrelated code or timing changes.

Another issue with ASan and UBSan, is that every application has to run them (and maintain its own test suite comprehensive enough to make them useful). With static checks, a memory-safe library is memory-safe for everyone, even for applications that aren't particularly careful with their tests. The library author is able to express their safety requirements through the language, and all callers have to respect those requirements all the time.

All the tooling you've just listed adds build complexity, on top of a build system that is already an abomination of makefiles, CMakeLists and lack of package manager. Let's not forget all the header files duplicating half of your implementation.

- runtime predictability. Our async high-load programs are already complex, and having a much more predictable runtime (no GC) makes things feel much more straightforward

- lack of bracket need. You get destructors from your types! No more async-exception or other accidental leaks

- no exceptions. The “?” syntax is truly genius, Holy Grail of Haskell error handling coming to life

The O’Reilly book by Jim Blandy and Jason Orendorff. It is a really fantastic book on a programming language, the best I’ve ever read. The new edition is due this year it seems.

https://www.oreilly.com/library/view/programming-rust-2nd/97...

Today online you've got full text search, maybe you find two, three hits that are irrelevant, but it's so cheap you barely care. And in a book today the index is probably auto-generated (hiring somebody to write an index is not a thing these days) and so it's almost useless with dozens of irrelevant entries, but hey, like I said, full text search, so who cares?

Because C is such a small language and it was essentially finished when the book was written, they get to do a pretty complete survey while also teaching you, so you read the book once, now you understand C pretty well. The Rust book is much better than C++ books I tried, but because Rust is still immature there are big sections that are being rewritten or have already been rewritten, and of course the whole book can't be reordered and started over each time, so overall it's uneven.

I am reluctant to buy a printed Rust book because of that immaturity. My (second edition) K&R is still a pretty good survey of the language. Are there things it doesn't cover? Yes. But few of them are fundamental, whereas I feel like if I bought a Rust book today, in five years it's a historical curiosity like my Stroustrup, except hopefully better written. I still consult my K&R a few times a year, I don't even know where the books I own on other languages (including the long obsolete Stroustrup) are, I might not have unpacked them after moving years ago.

The core feel of Rust is very much the same today as it was then. Just things got smoother overall. We'll see in ten more years.

(This is on my mind, as we'll eventually be releasing an updated book for Rust 2021, at some point. Probably early 2022. It will grow in size again, mostly due to adding stuff about async/await, which is a major new addition to the language, but only needed in certain circumstances.)

It's a pain in the ass in it's own way, but you're kinda stuck with it if you want to do mainstream ML.

As a language it's dumber in some ways that JS, definitely slower in some cases, but also way less weird. Prototype chains and stuff are a cool demo that BE knew about Self and shit in the week he had to write JS, but anyone who claims they like that has Stockholm's syndrome worse than someone who thinks Ruby metaclasses make sense.

That said, the more interesting question is TypeScript vs Rust. I can see how the complexity of C++ naturally leads folks to Rust. But I’ve had a hard time choosing Rust over TypeScript when trying to implement a basic service.

It’s absolutely true that Node.js web servers aren’t optimized for multi-threaded data access times and the Node.js event loop can get in the way of responsive performance.

But at the same time once you build, for example, an HTTP 1.1 web server for Node that is similar to what you’d build using semi-unsafe code in Rust and ships by default in Go standard library, it’s hard to say that JS is any less efficient than Rust when both are generally written to use async/green thread runtimes, make calls using a pool of Postgres or database connections, and either have PG return JSON or otherwise reshape and assign the results to a data model.

Given more computing power, Rust obviously wins, but if you’ve a single thread to work with, and a small buffer so after each web request is served, GC can do its thing… where are the tangible Rust benefits besides maximum speed?

I suppose I’m cheating by suggesting you could use Actix to power your Node application, but the problem I’m facing is that Rust is really complicated to learn and there are few frameworks that make it easier. The amount of published and shared knowledge there is around Go, PHP, TypeScript, Python and Ruby is enormous. Yes, Rust is clearly easier to learn than all the warts of C++, but it feels like Rust hasn’t gained enough traction to convert TypeScript fans, for example, or at least those building APIs and front ends.

I’d really like to be convinced to use Rust because of how easy it is compared to TypeScript but I haven’t seen anyone actually suggest that in practice. Go? Yes, it’s easier to learn than to understand both JS and TS and you can put up with the lack of generics by having more verbose code compared to TypeScript. But Rust? Is it just the case that these other languages are more mature such that all the blog posts have been written?

Also note that the hardest problem when getting started in any new language is package and framework selection. Unless you follow a book that has already picked a handful of packages such that you’re happily falling into the pit of success, I recognize that all languages (except maybe Rails or Spring) force the user to make hard choices upfront about their dependencies. But the only book I’ve seen that presents a coherent narrative for Rust APIs is Zero2Prod[1] and I’d feel more confident if there was at least one other similar set of learning materials.

1. https://www.lpalmieri.com/ for the book published as blog posts, https://www.zero2prod.com/ to buy.

* http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...

* http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeym...

* https://gregoryszorc.com/blog/2021/04/13/rust-is-for-profess...

C++ is not even close in that respect. Duck typed generics, lack of borrow checker, lack of sync/send markers for multithreaded code, easy-to-abuse overloading (that's even abused in the standard library, so there's no escaping it), legacy cruft that springs up in unexpected places, non hygienic macros, exceptions and frankly I could go on for quite a while.

I think for some of us Rust is effectively the promised land. I learned some Lisp and Haskell but I could never really get into them seriously because despite some cool language features I just don't like paying the performance costs of a heavy runtime, dynamic typing and garbage collection. So instead it was C and C++ for better or worse. But then Rust came out and said "hey, how about having your cake and eating it too?" and I never looked back.

But of course many people don't share the same objectives. If Haskell and Common Lisp are what you consider to be your baseline I can definitely see how Rust's very strict type system would be seen as an annoyance, especially if you don't mind paying some runtime performance cost for the sake of simplicity and speed of development.

I think it was on a previous HN story where Rust programmers claimed that to get around borrow checker errors they just clone things. Now, the code may compile and technically be correct, but it hardly exemplifies the attention to detail normally required by a systems engineer.

It may be a bit of a No True Scotsman but in my experience hanging in Rust IRC channels and similar places, the devs who tend to clone and slap `Rc<RefCell<_>>` all over the place tend to be those who come from garbage collected languages, simply because they're really not used to thinking about ownership.

People who come from C, C++ and other non-GC languages are effectively already used to dealing with ownership and lifetimes, it's just that in those languages it's up to the developer to keep track of them. In terms of overall architecture I don't find that I write Rust much differently from C++, I use RAII most of the time and when that doesn't work out I'll carefully chose between cloning or some smart pointer/container.

IMO Reference counting and cloning should be the exception, not the rule, and I'd go as far as saying that if you find yourself cloning and boxing data all over the place in your Rust application you're either working on a very atypical application or you're doing it somewhat wrong.

Same here, though I do find myself deviating sometimes. Specifically there are cases in C++ where I could write code that makes less copies or handles data more efficiently but I don't because the approach would be more error prone. In rust these more risky approaches simply result in having more compiler errors instead of crashes or other runtime bugs.

There are a lot of programmers who approach new languages by trying to write in the style of their previous language. That’s not really optimal, but it can get you up and running quickly producing passable results for a wide variety of (previous, next) language pairs.

Rust is not one of these languages. If you don’t try to “get” Rust and continue working across the grain, you’re going to have a rough time of things. Rust brings along an entirely new concept of explicit ownership that’s implicit in other languages, and if you simply try to push forward without internalizing those restrictions (and understanding their implications on how to structure your programs), the Rust compiler will never stop pushing back against you.

While there are legitimate reasons to need Rc<RefCell<_>>, to Box things, and to clone(), the vast majority of Rust code doesn’t need to fall back on them. If you find yourself instinctively and repeatedly reaching for these as a quick workaround for borrow checker complaints, it’s going to be much better in both the long and medium term to try and understand what the compiler is trying to tell you about your overall approach to design.

This is, I think, the biggest area where Rust evangelists can make some big strides. There are a lot of program designs that compile just fine in other languages but that Rust rejects (or pushes back against) for Very Good Reasons. And getting new developers over that hurdle where they understand how to internalize enough about ownership upfront that they can come up with approaches that work with the grain is a hard problem, and I’m not sure how to solve it. There’s a moment where something clicks and Rust goes from being a fight against the borrow checker to something where your designs just work out of the gate and I don’t know how to get that click to happen quicker.