There's no need to resort when popping an item.

When adding an item, it gets added to the next unused vector element. The sorting range end offset gets updated.

Then it sorts (note you would actually need a custom sort since a PriorityQueue is a pair)

  std::sort( vec.begin() + startOffset, vec.begin() + endOffset ) [1]

Adding an item would be something like:

  endOffset++; vec.insert( vec.begin() + endOffset, $value );   [1] 

Or maybe I just used

  endOffset++; vec[endOffset] = $value;  [1]

Popping an item:

  startOffset++;

[1] Im writing this from memory from my attempt many months ago. May have mistakes.. but should communicate the jist

Also, if you’re building binaries for redistribution, requiring Haswell or newer is kind of an aggressive choice.

I have a box that old that can run image diffusion models (I upgraded the GPU during covid.)

My point being that compiler authors do worry about “obsolete” targets because they’re widely used for compatibility reasons.

Oh, yeah. Looking at the code the comparison function is bad in a way that will hit issues with cmovs. The "else if" there is a nearly 100% predictable branch which follows a branch that's probably completely unpredictable. One optimization you get with -O3 is that branches not marked likely or unlikely can be turned into dataflow. The proper ordering for that code is to pull the equality check forward into an if statement and mark with "unlikely" if you're using -O3, and then return the ordering of the floating point comparison.

Since we're using Rust there's some decent syntactic sugar for this function you can use instead:

    let cmp = |other: &Neighbor| -> Ordering {
        other.dist.partial_cmp(&neighbor.dist).unwrap()
            .then_with(|| other.id.cmp(&neighbor.id))
    };

You probably won't get any CMOVs in -O3 with this function because there are NaN issues with the original code.

For what it's worth, you may be pleasantly surprised by the performance if you upgrade. I went from an Ivy Bridge processor to a Zen 3 processor, and I found that there were a lot of real world scenarios which got noticably faster. For example, AI turns in a late game Civ 6 map went from 30s to 15s. I can't promise you'll see good results, but it's worth considering.

What factors would be compelling to upgrade for?

Just curious, since perf alone doesn’t seem to be the factor.

https://browser.geekbench.com/processors/intel-core-i7-2600k

https://browser.geekbench.com/processors/intel-core-i9-14900...

The reasons do not matter here. It is still ugly / noisy / overly-complicated and probably could have been done better.

I understand pattern matching deconstructions, I have seen it in other languages. Funnily enough they were nowhere as ugly / noisy / complicated as Rust's is. Rust seems to have bolted on a lot of fancy shit that may be appealing to a lot of people and that is it.

In your link, the first one is fugly, the last one is fine. Maybe Rust just encourages ugly (i.e. complicated) code a bit too much.

I'm actually fine with almost all the decisions that Rust made in terms of logic and concepts, but specifically don't like the synthax itself: the symbols, keywords like the consonant-only "fn" instead of "func" for instance, the fact that || {} starts a lambda instead of || -> void {}, the fact that you can return things by simply having them in an if branch. It's the main reason I don't use the language.

"if let" just breaks my brain, it feels backwards to me and takes me a minute each time to work out what's going on. In 40 years of programming I've never seen a syntactic construct that I found less intuitive. And it would probably be easily fixable, if it was more along the lines of "if x matches Some(let z)".

  let Coordinates(x, y) = get_coords();

  let Some((x, y)) = get_coords() else { return };

They could have at least put the types on the left. Types on the right are a good fit for mathematics, where everything is single-letter symbols, so your eyes do not have to go across the line to see the entire definition, but in programming function definitions often span an entire line on screen, so the most important information should be the first thing shown! Also most programmers do not have formal education in mathematics, so the whole "function : domain -> image" syntax is foreign to them. We really should strive to democratise programming for everyone, rather than make it isolated to a small clique of "properly" educated white men who all went to the same university.

The type of a variable and the return type of a function are the most important pieces of information regarding those, so they ought to be on the left. It also fits the data flow going right to left (i.e. how the '=' operator works). C's type declarations can get pretty gnarly, so there is definitely room for improvement there. I would say Java (and C#) got it as close to perfect as possible.

If you want to replace C/C++ you should make your language look as inviting as possible to users of the old one. I truly think this strange fetish for putting types on the right is what gives C programmers the ick when they see Rust for the first time and is hampering its adoption.

I have the opposite experience: C++ is what I have the most experience with by a very wide margin, but I find reading other people's rust code way easier than other people's C++ code. There's way more weird features, language extensions and other crazy stuff in C++ land.

It reminds me the experience I had when working with Scala, I really tried to like it but the mind-boggling amount of features created similar issues.

It took me about 2 years to feel somewhat comfortable but I'd still run into code where someone decided to use their own set of unconventional favourite features, requiring me to learn yet-another-way to do the same thing I had seen done in other ways.

I just got tired of it, didn't feel more productive nor enlightened...

It probably takes a week to get used to ugly pants too. OP's point is a matter of aesthetic judgement. I don't mind it either, but = |&I: can| -> Agree { Rust::Syntax }; is.a(Bit(&mut chaotic);

Every time a language developer chooses to give their new language a novel, let alone chaotic, syntax, they sin against the very premise of software development being an engineering profession. Can you imagine the madness if mechanical engineers had the same laissez-faire mentality towards the conventions and learned best practices of their field? Randomly chosen bolts to use left hand threads just because it suits their arbitrary whim, every thread has a unique pitch never seen before just to make the machine stand out from the crowd. Parts of the machine use hot rivets, not because the design demands it but because it scratches a retro aesthetic itch the designer had that day. Every time a new machine is designed it has a whole class of new never before seen quirky ways of being put together and any mechanic who pleads for standardization on common sense ways of putting a thing together are just told to git gud because the creative expression of the 'engineers' is paramount.

(This is how we end up with German cars, isn't it?)

Laughs in lisp

  (defun fib (n)
    (declare (type (Integer 0 100) n))
    (the (Integer 0 *)
         (if (< n 2)
             n
             (+ (fib (- n 1))
                (fib (- n 2).)

More than C? Highly doubt that.

Everyone who tells me this, I would love them to write an useful project in Forth. ;)

Guess what? They would blame Forth, Common Lisp, etc., yet I could tell them the same things I am being told about Rust.

HN is not some monolithic single perspective. There are plenty of Rust fans here, and they show up just as frequently as the complainers. In fact, there is overlap between the two groups. You can be a fan of a tech and still complain about its warts.

Oh come on, how many times have we seen "blazingly fast in Rust", "rewritten in Rust" etc.? Many times. We get it. You like Rust. This "rewrite in Rust" bullshit is just as nauseous and I am sick of seeing it, too. So what? In fact, it is quite a meme now.

Please, every time you see someone praise Rust (every other day), tell them the same as you have told me, just the opposite way around.

> Using Vec for arrays is also annoying, repeating the mistake from C++.

Neither Rust nor C++ uses vectors as array, they're distinct things.

An array is a fixed-size object, which never allocates and its elements thus always retain their memory address. In Rust they're `[T; N]`, in C++ `T[N]` or more recently `std::array<T, N>`.

A vector on the other hand is dynamically sized object, that may (re)allocate to accomodate new elements, and the address of their elements can change. In Rust they're `Vec<T>`; in C++ `std::vector<T>`.

I genuinely don't understand how you can find the type names for numbers hard to read, nor how you can say the size is treated as more important. The first thing in the type is what kind of number it is!

I dislike macros for that reason when reading code on GitHub or Docs.rs, but Rust was kind of made to be used with an IDE (or LSP).