Yeah, the quality on Lemmy is nowhere (...)

Go ahead and contribute things that you find interesting instead of wasting your time whining about what others might like.

So far, all you're contributing is whiny shitposting. You can find plenty of that in Reddit too.

Ergonomic keyboards are not a result of “the size of the keyboard”, but the shape.

I apologize for the mistake. Even though I referred to size, what I had in mind was geometry/layout.

Without any real studies on it mentioned so far you’re relying on gut feeling and logic here.

Are there actually any studies suggesting that ergonomic keyboards prevent RSI? As far as I could gather, there's a correlation between higher RSI incidence and keyboard usage, but nothing suggests ergonomic keyboards lead to a lower incidence of RSI.

I'm partial for the Royal Kludge RK84 for no particular reason other than it's one of the rare small form factor keyboards that has USB passthrough. It's a godsend if you use a USB security key, and it also helps if you need to plug in additional devices such as a USB headset.

If keychron had any model that supported USB passthrough, I'd update my recommendation.

I’d go with an ergonomic one to avoid pain on the outside of the wrists.

I might be totally wrong, but I firmly believe these ergonomic risk factors are not the root cause of these health problems, and instead they are indirect factors that are correlated with fundamental problems affecting a person's activity.

For example, tennis elbow isn't caused by a particular model of a tennis racket, nor is jumper's knee caused by a shoe model. Interestingly, I stumbled upon a post somewhere in the past that pointed out that Emacs users had a higher incidence of repetitive strain injuries than vi users. One of the most basic treatments of RSI is a combination of working on the patient's overall posture and rest, regardless of keyboard format.

If you're experiencing wrist pain due to keyboard usage, the time you spend typing is a far more important factor than what keyboard model you're using.

Here's a link to the actual C23 charter.

WG 14 N 2611- Programming Language C - C23 Charter

Perhaps the biggest news of Boost 1.84 is the introduction of Boost.Redis, a Redis async client library built on top of Boost.Asio.

Does anyone have any plans to start using Boost.Redis in their projects?

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I agree, but I don't think the problem is marketing. The problem is how some elements of Rust's community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that's not Rust. It goes well beyond a cargo cult mentality, and it's sad that a fine technology is dragged through the mud by those who were expected to show its value.

The most asinine thing i encountered is that the bracket operator on std::map writes 0 value if the key is not found.

That's a "you're using it wrong" problem. The operator[] is designed to "Returns a reference to the value that is mapped to a key equivalent to key, performing an insertion if such key does not already exist. "

The "0 value" just so happens to be the result you get from a default initializer whose default initialization corresponds to zero-initialization.

If you want to use a std::map to access the element associated with a key, you need to either use at and handle an exception if no such key exists, or use find.

Should focus on getting rid of undefined behavior.

What problem do you believe is presented by undefined behavior?

As a rule of thumb, I would say that recursion should never be used in place of a for loop.

If you don't know what you're doing with a recursive function then you risk pushing stuff to your call stack proportionally to the number of items you want to iterate over.

If your collection and/or the size of the stuff you're pushing to the stack is large enough, your app will crash.

If you know enough to avoid growing the call stack then you know enough to not rely on third parties to figure out if you need an iteration of recursion.

Having said this, I'd say that OFFSET+LIMIT should never be used, not because of performance concerns, but because it is fundamentally broken.

If you have rows being posted frequently into a table and you try to go through them with OFFSET+LIMIT pagination, the output from a pagination will not correspond to the table's contents. Fo each row that is appended to the table, your next pagination will include a repeated element from the tail of the previous pagination request.

Things get even messier once you try to page back your history, as now both the tip and the tail of each page will be messed up.

Cursor+based navigation ensures these conflicts do not happen, and also has the nice trait of being easily cacheable.

This blog post writes a dissertation about garbage collection, heap memory management, the absolute need to take courses on assembly language, and other contrived and absurd tangents.

Looking at the code, the guy gets a double-free because he instantiates two std::unique_ptr from the same raw pointer.

I'm sure the author felt very clever to pull up all these topics to write a blog post about, but in the end all they're doing is writing buggy code based on their misconception of a topic.