pleoxy

You can adopt a centralized system. And it's fashionable to do so. Lots of people here and other places advocate doing everything you can on the server.

But it's not required. Additionally, there are plenty of good incentives not to, including cost. Client CPUs are fast, free to use, and don't require a high latency network hop. Local ram, disk, and network transfer are also available in abundance. You can totally reverse the architecture where the client is doing the heavy lifting and provide the user a good experience.

Intel CPUs are inefficient when pegged, but more efficient at idle. On AMD your using the same cores the cloud is. Without the massive IO attached on the server side the client CPUs are more efficient for a unit of work. Apple is more efficient than the PC side presently, and Qualcomm is entering the fray and appears to be quite efficient.

So I'm really not certain where you're efficiency claim about client hardware comes from. All that hardware is just sitting there and sales vary, but they are not cratering for high performance local compute.

You have a point about GPUs, but only a very few very specialized applications need those.

What is that, 48 more states to go?

Definitely a better solution than the brick wall he hit. Complicated beastie. I can see the appeal if you just love, eat, and breath SQL.

But a query language within a query language feels bolted onto something alien to do something pretty basic. Pass. If I'm teaching this to new engineers, pass also.

I apologize for being short with you in my previous response. I need to be better about assuming good faith.

Your response seems to betray a certain ignorance of mongo. Don't you realize that mongo has indexes?

For handling documents, this blog post covers the topic in some depth.

https://jimb-cc.medium.com/postgres-jsonb-meets-mongodb-part...

Might I suggest you actually use mongo on a project before engaging further on the topic. It clearly has had a lot more thought put into it in the context of json documents.

If postgres works great for your use cases, great, go be happy with the tool.

All you do is poop all over the story about postgres. I'm convinced that no use cases will convince you of anything. I'm not really looking to involve myself in a database holy war.

When one doesn't want SQL for one.

Nosql is a fun target to beat up on of late. But there are good, even infamous, reasons to avoid SQL. Particular if you want to accomplish flexible record queries from untrusted clients.

Unless it's not.

Nothing wrong with picking mongo if it's a good fit for your use case.

> True, but SaaS still runs on cloud infrastructure so the costs are still there

You can bring the costs way down. Their margins include a pretty insane amount of features that not everyone needs. There is a lot of meat there if you have skills in the area.

Making/saving money via DIY compute is an area ripe for improvement via better vertical integration.

The big cloud providers simply do not have this market cornered even with this mind share that prevents perfectly good engineers from seeing the path plain before them.

Some of us do, actually.

It's been a while, but this was my experience. Lots of dev hours burned fighting with expo.

You completely missed the nuance I tried to convey.

Making a giant bucket of lots of things and declaring it bad because there is something bad in there shows your ignorance.

Ignoring reasoning shows an unwillingness to learn about stuff.

A totally generic and unthinking generalization.

There is a place for religion. Something that pushes you to be better than you are. Along with the happiness and fulfillment that comes from that effort. Selflessness, love, compassion, truth.

Plenty of bad religions telling you that you are perfect the way that you are. Just give me money, fame, or influence and I will flatter you and pump your ego.

Another form of this is flattery in exchange for hating something. Many doomsday cults fit this category. All your life problems are because of 'insert target X'. But I, I have the answers you need.

Religion is more attuned with purpose, where your heart is, than the belief in God. Though the two are often paired.

And yes, we crave purpose.

First example is not clear cut at all.

The project sounds successful overall to me. Yes, they had to do more than they thought going in. That describes most engineering efforts.

Does the author think that operating system API churn just won't affect native somehow? Or be improved when even more of your application surface area is in the native space?

If you need PLP use an enterprise drive. That's what they're for.

So, my state has laws on the books to explicitly protect reasonable solo outdoor play.

I still get reported by random people if my kids are outside, in our own front yard, without a visible parent watching. They call the cops, sometimes other agencies.

The police come and lecture me with a tone that I shouldn't do anything that might cause someone to call. That they shouldn't be in our own yard without direct supervision.

The agencies will sometimes come do a "wellness check" when you have enough reports against you. It's really creepy having state agencies looking for problems at your place that have nothing to do with the reports.

If you fail they can haul off your kids. Lots of rumors that they can be capricious and don't require any court proceedings.

So I don't let my kids play much outside. Nobody seems to care what is reasonable or legal.

Move him to a phone intended for the purpose, Gabb has options.

Purely in hardware costs. More like $200/mo payment can be replaced by $100-130 in hardware.

For $600 I can get hardware that outperforms a $1200/mo ec2. Easy.

It does slow some of us down. It's not really about terseness. I can write code that works on all primitives that might be sent down pretty easily. That code, sometimes is longer than limiting the inputs by types would be. I can also write code such that it only runs if the structure of the data is as required for that code to run, allowing for nulls or missing nested objects.

These two patterns allow you to write most code, type free, that gracefully handles anything you throw at it while always doing the right thing.

Making changes to such a system is easy and friction free.

Not many type advocates speak of the downsides of type systems, always pitching the net win and ignoring the actual cons.

When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I get that having discipline in code patterns and the required robustness is a difficult ask at some organizations and some devs. In that circumstance it's better to have a minder in a type system that enforces base the conventions for everyone.

The word you are looking for is responsible.

Someone who will take burdens from you and go handle them themselves and don't need to be cajoled, directed every step, motivated, managed, etc.

There is crossover with smart, but that's just a nice to have - responsible is the primary attribute you need here.

Plenty of smart or even brilliant and still lazy people out there that will not fit here.

Pretty confusing to call their target a "service worker" when that is also the name of an in browser platform. Kind of a mess of a post.

All of the AMD chiplet based designs do poorly at idle power.

These monsters will do better than the 39xx because of the 6mm IO die. But it's still going to have high idle power compared to a monolithic Intel design.

The monolithic AMD dies (laptop/mobile) are competitive in the idle power space.

Till layoff do us part.

How could I miss that it's fundamentally part of everyone's martial vows?? /S

Marriage is about love, companionship, and children. Particularly because of children there will always be a significant economic component. But it's not the driver, it's a supporting component.

You don't buy a marriage. If you try you are doing it wrong.

Finances are a component of marriage, not the driver.

Been doing it for more than 15 years.

Where there is a will, there is a way.

Except that classes are more memory efficient and better optimized in the VM.

This will package a copy of the functions with every instance you make, the class variant will only create member variables for each instance.

Maybe save a few bytes down the wire with a different developer experience for fundamentally more bloated code.

> Many experts in drywall installation before drywall screws were popularized swear that screws are slower and worse.

Screws are superior as an end product. Old houses will tell you that with the amount of creaking and slop that builds up with nails.

But there are videos floating around about the expertise of some old nail drywall experts. Holy smokes it could be fast. They are probably right about the speed.

This lacks context. Avx-512 is disabled (fused off) in the big cores of Intel big.little. In the server and workstation chips that only have big cores, it is functional.

It's right here in black and white. https://www.intel.com/content/www/us/en/products/sku/233483/...

You can get 48GB dimms now for 96GB from just two sockets.

But yes, there's definitely a memory speed limitation there.

Last I looked into this it was around 30MB. wasm does compress really well.