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.
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.
my point was that I was able to find answers for everything else before I had to resort to posting a question.
That's not a SO problem per se. Some projects do use SO as their semi-official customer support channel, but in general posting a question on SO is not supposed to be better than posting a question on Reddit: you get what you paid for.
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.
"Appendable” seems like a positive spin on the (...)
I don't think your take makes sense. It's a write-only data structure which supports incremental changes. By design it tracks state and versioning. You can squash it if you'd like but others might see value in it.
It’s usually easier imo to separate them into different processes (...)
I don't think your comment applies to the discussion. One of the thread pools mentioned is for IO-bound applications, which means things like sending HTTP requests.
Even if somehow you think it's a good idea to move this class of tasks to a separate process, you will still have a very specific thread pool that can easily overcommit because most tasks end up idling while waiting for data to arrive.
The main take is that there are at least two classes of background tasks that have very distinct requirements and usage patterns. It's important to handle both in separate thread pools which act differently. Some frameworks already do that for you out of the box. Nevertheless it's important to be mindful of how distinct their usage is.
Is there a simple way to do a http web server or socket?
What's your definition of http web server or socket? Most frameworks nowadays provide you with tools to get a fully working project up and running with just a couple of clicks.
For instance: https://start.spring.io/
The problem with desperate monetization stunts like this video is that they rarely have any relevant content to show, and they are a formulaic output of mixing clickbait titles with 15min of inane fluff.
Microservices are not just about scaling and performance but it is a core advantage. To say they have “nothing” to do with it is outright false.
They have nothing to do with performance. You can improve performance with vertical scaling, which nowadays has a very high ceiling.
It's not a coincidence that startups are advised against going with microservices until they grow considerably. The growth is organizational, and not traffic.
Microservices are about modular design and decoupling units of code from each other.
Yes, but you're failing to understand that the bottleneck that's fixed by peeling off microservices is the human one faced by project managers. In fact, being forced to pay the microservices tax can and often does add performance penalties.
The problem with this approach is that switching from vertical to horizontal is extremely hard if you didn’t plan for it from the start.
I think you're missing the point that more often than not ain't going to need it.
In the rare cases you do, microservices is not a magic wand that fixes problems. The system requires far more architectural changes that go well beyond getting a process to run somewhere else.
This is a baseless assertion from your end, and a purely personal one.
My anecdotal evidence is that the best software engineers I know use these tools extensively to get rid of churn and drudge work, and they apply it anywhere and everywhere they can.