We worked with RAGs at work.

After a few months, we stopped working with RAGs at work.

It's a retarded system that cannot be perfected, only a % of accuracy will be achieved.

Semantic search SUCKS for specific information. For example, if you have a bunch of data that says "my phone number is xxx-xxx-xxyz" and then you ask "What is Sandy's phone number" it will say "I have no fucking clue!" because RAGs suck dick.

The best approach is hybrid - have a RAG that searches both a semantic index AND a traditional index. This way, you get both semantic and literal matches.

But it's still just throwing more money at the bullshit and hoping it grows into a flower. For us, it never did, and we got bored of spending money.

Good luck!

To be fair, if it exists in c, it also exists in c++. There was probably no rush to implement something that's already available.

@Lensflare I got iOS 26 the day it came out and have used it daily every day since. I generally can read it, but the old UI has a 100% success rate and the new glass is more of a 96% success rate. And I don’t even like the way it looks so it just got worse for no real reason!

Yeah well, when you get paid retail wages, you’re not a tech bro. You’re a retail salesman.

I returned a router the other day and he said “what’s wrong with it” and I said “the 5 ghz band has no internet access” and he was like “okay what’s wrong with it though”

Really awkward but what do you expect, an engineer?!

It should be allowed. Just like googling should be allowed. You should be allowed to use all the tools you normally use. It’s not a quiz, it’s an assessment of your skills: toolchain included.

That being said, you should be judged on your AI usage appropriately. Just like if you were to copy and paste your whole interview from Stack Overflow, using AI to generate your entire interview should be a FLUNK. The company wants to evaluate your productivity, yes, but they also want to make sure you can do work without grinding to a halt if AI spits out the wrong answer. Maybe get ahead of the game and give interview questions that AI struggles at or is difficult to solve with AI.

Hating on tools is for perfectionists. Us guys that need to meet deadlines don’t care about tools as much.

Without looking it up, here's my interpretation:

HashMap is just a regular hash map with an array on one side storing hashes, and a value on the other side (depending on implementation, this is typically a list due to collisions in hash maps)

HashMap = HashMapEntry[ {bin hash, HashMapValue[ ]} ]

LinkedHashMap sounds like the same thing, but linked list driven?

LinkedHashMap = Root = {bin hash, HashMapValue[], Node next}

@12bitfloat no idea frankly, all my comptime stuff is generally just lookup tables.

@Lensflare Zig was the first place I tried comptime code gen, and it was seamless. Completely wonderful, in fact. Barely any limits at all, you just write regular code (which *reasonably* can be comptime), denote the code and all of its inputs and outputs as comptime, and done.

As someone who got their degree in database design, this would be fun actually :)

xcodesucksanddontevengetmestartedoncontacts

I googled it (do not own a mac, just a poor boy) and it looks kinda cringe. I imagine it gets a lot worse if you actually try to use it. That's my honest take on the new liquid glass stuff (I have an iPhone, I'm not *that* poor of a boy).

The new iMessage app on my iPhone in particular seems really janky. The liquid glass in general is a little hit-and-miss (I HATE the outside shimmery border effect) but the new iMessage app, despite having some nice features like background pics now, just works like ASS. Scrolling up and down your messages is so janky, going from the list of messages to the chat view is janky, sometimes the bottom of the most recent text gets cut off, etc etc. It's so obviously the first version of this software that it's painful.

In 5 years, when they shake out all the kinks, liquid glass will be okay. Right now, it's *just* okay.

@BordedDev you mean Cherno? Cherno mentioned on my fucking 15-people-left dev ranting app?!?!?!?

Unrecognized symbol "hey" at line 1: "hey babe just letting you know I severely miscalculated the level of bullshit that this thing at work would be, and I need to finish it today or else my boss will crawl up my ass and tear me a new one from the inside-out. Love u". Maybe you meant to type that Into iMessage?

@jestdotty This comment isn't just funny (EM DASH) it's truly getting close to genius-level insight into the world around us. Let's break down why I'm sucking your dick crazy style [[some emoji to match the vibe]]

(bullet point) Please buy ChatGPT Pro.

Someone tell these fuckwits that CI/CD needs a robust automated testing framework, it doesn't just mean you get to push to prod automatically because you feel like it.

And the elephant in the room, set up a FUCKING dev and QA environment for the LOVE of CUNTS.

One of the reasons I love C# (in .net core, not .net framework/standard) is how nicely it plays with JSON.

class Person {

string? Name { get; set; }

}

...

try {

var person = JSONSerializer.Deserialize<Person>(string);

}

catch (JSONParseError jpe) {

Console.WriteLine("That's not a fucking person!");

}

@wojtek322 America is more about economy than people. Whatever, it could be worse; it could be about neither economy nor people.

Yeah, well, if you saw the other side of the job market (hundreds of liars and cheaters, mostly from India, sorry), you'd understand. If you post something on LinkedIn looking for a 5+yr ruby dev, you'll get 500 python devs (straight out of college) just throwing their hat in the ring, plus another 500 that say they know ruby but don't, etc.

ONLINE job markets are ruined. We need local again.

Holy fucking shit I get 12 holidays and that's high for America.

"Hey, we noticed that all of our servers make a call to what appears to be your personal Apple Watch about 3-4 times a day, just wondering what in the fuck?"

@djsumdog I love coming across people that just know shit about shit that I don't know about. The ability for someone to pull out an extremely specific example because they've been there is such a pleasant thing to see. Bravo, and no homo.

@Wisecrack @hjk101 I would somewhat argue that's the language's fault for having such a breadth of supported use cases. Something like c is beautiful because most people write the same c. Python, despite the brainless hacks that tend to use it, also looks pretty similar from codebase to codebase because the language has a standard in mind and the syntax, stdlib, and other resources reinforce (without forcing) that.

c++ is just "we need a language that can do everything, all the time" and it's suuuuuuuuch a mess. You could be an absolute master with c++11 and move on to a c++17 codebase and it's like you're back at day 1 in uni.

Is it bad? Maybe not. It *does* make for likely the most capable language available today. However, it most certainly is frustrating, and a big mess!

Relevant YouTube link (I have personally watched and recommend this video): https://youtube.com/watch/...

Edit: the AI voiceover might be jarring. He does it because he has a strong accent, this channel is NOT AI slop at all.

@Wisecrack I may have been overly-critical. I didn't intend for you to catch the flak of all other parallel processing n00bs. You're a smart guy and your ideas are good. Concurrency is a topic that you need to get a feel for, a lot of things in the field that seem logical are actually counter-intuitive. For example, parallel processing actually has a ton of very heavy overhead so even if you parallelize a problem properly you might see performance loss compared to single-threaded computation. It's a bit wild sometimes frankly.

The good rule to remember (both in life and especially computer performance): there is no free lunch!

Your idea is neat. I HIGHLY recommend a channel called "Core Dumped" on YouTube. He has some parallel processing videos and you'll see that your ideas are not actually that far off schemes from the past.

@12bitfloat that's what I'm trying to say, it genuinely works well for just about any concurrency problem. My example reduces and joins data, but other applications might give each thread a bucket of data for queues, requests, messages, whatever - and a parent thread just glues it all together.

Multiple threads rarely need to communicate back and forth with high bandwidth. Typically, they just do their work and join back with a main thread when the work is done. Video games are the same; you have a thread or two running physics, graphics, network, windowing, etc. They can all orchestrate just before a frame buffer swap (screen update). Typically the graphics and physics don't need to be in constant communication, for example.

Here's the summary portion of ChatGPT's answer:

If it were me, splitting firewood at home over weeks / months, I’d prefer a wooden handle (hickory or similar). The comfort, replaceability, and swing feel are worth the extra occasional maintenance.

If instead I were hauling an axe to remote sites, or using it in harsh conditions, where I can’t babysit the tool, or I want “set it and forget it”, I might lean toward a steel-handled or composite/steel-core axe — but I’d probably choose one with features that mitigate vibration (rubber grip, shock-reducing design).

I'm on the fence. ChatGPT is a powerful tool for things like that and I don't want some retard making a homemade nuke two blocks away from my house just because ChatGPT was able to give detailed enough instructions.

But the handle of a splitting axe? (FYI I actually tried this one and it didn't complain. Did you use the same chat for all of these queries? Maybe you made it suspicious!)

@Lensflare he was amputated... but luckily he was fine!

Also: isn't this a cooperative scheme because all of the threads need to cooperate upon the same counter?

@12bitfloat I tend to solve concurrency by pre-allocating memory and allowing my threads to consume as much is needed, then syncing all the results back together at the end.

For example, need to sum a list of numbers? Allocate an array that is n items long, where n is the number of logical units on the processor. Each LU will sum a fair portion of the input array and place it into its reserved spot in the memory (thread 1 gets spot 1, etc). Then, after all threads are joined back with the main thread, sum the mini array.

This is in opposition to something like a mutex or semaphore where each thread might want to update the shared total sum, creating a bottleneck. In this example, it's obvious. In real-world examples it can be less so. In fact, I can't think of any time I've actually used a thread lock to solve a concurrency problem.

Another thing to consider with concurrency is "is the juice worth the squeeze?"

Concurrency generally implies high performance computing, so every op counts. Modulo is not free. Iterating a counter is essentially free, but still not. Comparisons for each read/write are not free. Traditional sync methods are probably still out-performing this prime queue scheme.

There is no such thing as concurrent writes without waiting or CAS or some other sync method (such as eventual consistency with databases). It's not physically possible, and people just tend to end up inventing queues in more and more complicated manners.