I just gathered enough money to build my new PC. I'll even go to another country to pay less taxes, and this spike hit me hard. I'll buy anyway because I don't believe it will slow down so soon. But yeah, for me is a lot of money

I was planning to buy new in October but decided to wait. That was a bad decision and I had to go down from 64 to 32GB, while still paying more.

Fun times.

Me too. I had saved up to make a small server. I guess I'll have to wait up until 2027–2028 at this rate.

Buy used gear and rip out the guts???

That too is becoming overpriced. Besides, that makes it hard to find what you're looking for, and it doesn't speak to the fact that we, the people, also deserve to be able to buy new stuff at reasonable prices, without some cartel doing price fixing.

I am sure it sucks if you had a build planned. I had to shelve a build when graphics cards shot a few years back all the sudden.

In general, I can't but help think it feels like something we will remember in the future as a marker of the peak of the LLM bubble.

I know it's unrelated but does anyone knows a good paper comparing vector searches vs "normal" full text search? Sometimes I ask myself of the squeeze worth the juice

“Normal search” is generally called bm25 in retrieval papers. Many, if not all, retrieval papers about modeling will use or list bm25 as a baseline. Hope this helps!

Not aware of a specific paper. This account on Bluesky focuses on RAG and general information retrieval

https://bsky.app/profile/reachsumit.com

Compared in what? Server load, user experience?

Unwrap isn't a synonym for laziness, it's just like an assertion, when you do unwrap() you're saying the Result should NEVER fail, and if does, it should abort the whole process. What was wrong was the developer assumption, not the use of unwrap.

It also makes it very obvious in the code, something very dangerous is happening here. As a code reviewer you should see an unwrap() and have alarm bells going off. While in other languages, critical errors are a lot more hidden.

I hate that it's a method. That can get lost in a method chain easily enough during a code review.

A function or a keyword would interrupt that and make it less tempting

Well, you can request Clippy to tell you about them. I do that in my hobby projects.

> What was wrong was the developer assumption, not the use of unwrap.

How many times can you truly prove that an `unwrap()` is correct and that you also need that performance edge?

Ignoring the performance aspect that often comes from a hat-trick, to prove such a thing you need to be wary of the inner workings of a call giving you a `Return`. That knowledge is only valid at the time of writing your `unwrap()`, but won't necessarily hold later.

Also, aren't you implicitly forcing whoever changes the function to check for every smartass dev that decided to `unwrap` at their callsite? That's bonkers.

I doubt that this unwrap was added for performance reasons; I suspect it was rather added because the developer temporarily didn't want to deal with what they thought was an unlikely error case while they were working on something else; and no other system recognized that the unwrap was left in and flagged it before it was deployed on production servers.

If I were Cloudflare I would immediately audit the codebase for all uses of unwrap (or similar rust panic idioms like expect), ensure that they are either removed or clearly documented as to why it's worth crashing the program there, and then add a linter to their CI system that will fire if anyone tries to check in a new commit with unwrap in it.

Panics are for unexpected error conditions, like your caller passed you garbage. Results are for expected errors, like your caller passed you something but it's your job to tell if it's garbage.

So the point of unwrap() is not to prove anything. Like an assertion it indicates a precondition of the function that the implementer cannot uphold. That's not to say unwrap() can't be used incorrectly. Just that it's a valid thing to do in your code.

Note that none of this is about performance.

> when you do unwrap() you're saying the Result should NEVER fail

Returning a Result by definition means the method can fail.

> Returning a Result by definition means the method can fail.

No more than returning an int by definition means the method can return -2.

> No more than returning an int by definition means the method can return -2.

What? Returning an int does in fact mean that the method can return -2. I have no idea what your argument is with this, because you seem to be disagreeing with the person while actually agreeing with them.

> What? Returning an int does in fact mean that the method can return -2.

What? No it doesn't.

  fn square(n: i32) -> i32 {
      n * n
  }

This method cannot return -2.

Though in this case it's more like knowing that the specific way you call the function in foo.rs will never get back a -2.

  fn bar(n: i32, allow_negative: bool) -> i32 {
      let new = n * 2;
      if allow_negative || new >= 0 { new } else { 0 }
  }
  bar(x, false)

What? Results have a limited number of possible error states that are well defined.

Some call points to a function that returns a Result will never return an Error.

Some call points to a function that returns an int will never return -2.

Sometimes you know things the type system does not know.

The difference is functions which return Result have explicitly chosen to return a Result because they can fail. Sure, it might not fail in the current implementation and/or configuration, but that could change later and you might not know until it causes problems. The type system is there to help you - why ignore it?

Because it would be a huge hassle to go into that library and write an alternate version that doesn't return a Result. So you're stuck with the type system being wrong in some way. You can add error-handling code upfront but it will be dead code at that point in time, which is also not good.

As a hypothetical example, when making a regex, I call `Regex::new(r"/d+")` which returns a result because my regex could be malformed and it could miscompile. It is entirely reasonable to unwrap this, though, as I will find out pretty quickly that it works or fails once I test the program.

Yeah, I think I expressed wrongly here. A more correct version would be: "when you do unwrap() you're saying that an error on this particular path shouldn't be recoverable and we should fail-safe."

Division can fail, but I can write a program where I'm sure division will not fail.

Krishna is a high quality engineer, pretty happy to see the good work he is doing on Iggy. Pretty excited with the future of the project as well.

Thank you, and yes, 100% agreed about Krishna's work! :)

I coined it as underground precisely for that, it's just a handmade website hosted in a VPS by some random dude

Author here. It's my first technical blog post so any feedback is appreciated.

Also, if this sparked any design idea please don't hesitate to reach me, I'd love to try to implement it and/or debate it :)

Unfortunately I bet that 90% won't even reach at that part and just ragebait based on the title. The golden rule of modern age is always do the disclaimer as soon as possible.

Or you could skip the rage bait title entirely?

The one they changed the HN title to be… basically remove the “You don’t need Kafka” bit.

Oh I never sad the original, that's why I was confused. Thanks.

Maybe, but I know Leandro, it was more a joke than anything else. People just don't chill, the post is cool

I'm truly curious to know why would this be rude, seriously. Maybe it's a cultural mismatch.

For me ragebait and rudeness are things like: "X sucks, use Y", "If you aren't doing W you're losing money", etc.

He never said that Kafka sucks, nor anything related, obviously you can't replace kafka with only two signals. I'm asking with all politeness as possible, I just wanna understand what other people consider improper behavior

Nah, I wouldn't say this is rude or even a ragebait title. It's completely accurate and to the point...

That's fine, but then you shouldn't be surprised and complain when people respond to the rage bait.

The later the disclaimer, the funnier.

I'm thinking... couldn't a zig library infer the result columns at compile time with comptime and return a proper type to it?

Rust would have prevented that

You're not wrong but I think it's sort of irrelevant. Rust is cool but from my understanding, graphics card drivers are almost an entire OS in itself. I don't think Nvidia is writing a new driver for each GPU, I think they're using a core driver codebase and making relevant modifications for each card.

My point is that I suspect that the Nvidia driver is a decades-long project, and dropping everything and rewriting in Rust isn't really realistic .

Dropping everything is not necessary when porting to Rust, it can be done incrementally and starting with high-risk interfaces.

Which is what Microsoft and Google have been doing.

They made this "announcement" around 80 days ago here on HN :) [1]

1- https://news.ycombinator.com/item?id=44676691#44678172

The tone of this announcement seems a lot more certain than the previous one, at least.

I remember reading that comment. Disappointing article, but good to know it's still in progress.