I remember such a project, and due to our large and aging TypeScript frontend projects it would have added a couple of weeks to adjust all the types affected. All IDs in many places deep in code caused thousands of errors from the mismatch which was a nightmare. I can't remember exactly why it was so tough to go through them all, but we were under intense time pressure.
To speed things up we decided to correct the ID types for the server response, which was key since they were generated from protobuf. But we kept everything using number type IDs everywhere else, even though they would actually be strings, which would not cause many issues because there ain't much reason to be doing numeric operations on an ID, except the odd sort function.
I remember the smirk on my face when I suggested it to my colleague and at the time we knew it was what made sense. It must have been one of the dumbest solutions I've ever thought of, but it allowed us to switch the type eventually to string as we changed code, instead of converting the entire repos at once. Such a Javascript memory that one :)
I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.
Yes, as long as you are okay with your app only working on macOS 26. Otherwise you can already achieve what you want using Virtualization.framework directly, though it'll be a little more work.
As much as I agree with the sentiment, I can buy a firestick, Apple TV or Roku for a very small cost. Sure, a dumb TV would be lovely, but only because of a quicker boot time.
Given a dumb TV is going to be more expensive, I can't see a market for it based on a small marginal gain for the consumer. And 90% of people don't even care enough about the poor user experience vs the marketing that hypes up features no one uses or needs.
Boot time rarely matters since most TVs just sleep, and not shut down.
Cold boots are reserved for failure situations or updates.
I agree with the point that most people deal with terrible user experience.
A lot of my friends ask me why I went with an Apple TV when my TVs have built in functionality or I could use Roku / whatever Google call their dongles now for cheaper.
The answer is experience. I’ve tried to deal without an Apple TV and my god, the number of ads, the slow UI response, color handling etc.. all have me going back to the Apple TV.
But none of the stuff I mentioned is worth the price difference to the majority of people.
Yeah the Apple TV interface is so much faster, more responsive, and ad-free than virtually every built-in smart TV function. I don't understand how anyone, especially anyone remotely savvy, can stand to use them.
Even the "good" ones like the Android TV in my Sony is sluggish clunky garbage in comparison. I gave it a shot when I bought it, but couldn't stand it. Disconnected the TV from the network and just use the Apple TV and it's nearly perfect.
Do these providers really bring enough value to use them over a colocated managed db? (Not just the same region, but subnet etc)
I was under the impression for quite some time that it wasn't that bad to have 2-3ms latencies compared to a co-located DB which is typically <1ms. However, we recently switched from Neon to a colocated, managed db and there was a huge improvement. Some of our queries were executing sequentially (due to our ORM, Prisma), and so what was a 3 second transaction was reduced to only 1 second. Yes this could be rearchitected better, but it illustrates a major floor in my mind for these companies providing only a DB.
Managed vs. unmanaged is a massive difference and would be worth it. But these days I was under the impression most hosting companies also offer managed DBs.
Not everyone needs that kind of performance. Consider for example someone upgrading from an Excel spreadsheet. The fact that you can create a Neon database in just a few minutes, typing only 2 strings, is pretty incredible. And they don’t even ask for a credit card!
I havent used either beyond hobby scale, but I’ve followed both for a while because my day job runs a very large Postgres deployment.
You can run both Neon and Supabase in your cloud account by self hosting. They may also offer on-prem managed deployment, I haven’t looked. I think anyone at large scale interested in using them will “colocate” them.
They have different capabilities over the incumbent cloud provider managed Postgres service.
Neon is very interesting for:
- scale up & scale out. Get more cores for your DB than the max incumbent single instance size.
- fast SSD cache in front of S3. Incumbent DB often uses glacially slow network block storage like EBS.
- branching and schema management wizardry
Supabase is “just” a vanilla Postgres instance plus a suite of extra services and tooling. In their case the collocated version can add the services around an incumbent cloud managed DB.
Are these reviews completely paid for? What's going on here? Or are all the options awful.
I am in the position to choose our provider at our (small) company, but between Gusto and JustWorks and the majority of our employees being in Texas there was slim to none options except united.
UHC is great under one circumstance - if you and your family are all relatively healthy, so your coverage needs are just visits to the family doc or maybe an occasional injury. Many people fit that scenario, so may not realize that it can get bad once you start dealing with chronic problems, unusual cases, needing atypical prescriptions, etc.
Basically, it is a product made for the 80%, and the 80% don't realize how badly screwed the 20% are.
All the options are awful. Obama got in trouble for saying "if you like your plan you can keep it" when promoting the Affordable Care Act, because it wasn't true, but in some sense it was true because I truly cannot imagine any American liking their healthcare plan.
No matter how expensive your plan is, the simplest interactions like changing a birth control prescription or getting new glasses are absolute torture.
The criteria that your Forbes piece judges UHC on don't seem to be the things that people are complaining about. Seems that the Forbes piece is more of a surface-level judgement than anything.
Thanks for mentioning this. I did a bit of reading about the special alignment - very interesting stuff!
It seems like the alignment you refer to inspired the launch of Voyager 1 and 2 because they could visit so many planets at one time, and indeed it did slingshot them at quite some speed. However newer launches have reached similar speeds, and will escape the solar system due to improvements in launch technology.
Bomello | Hybrid, ~3 days a week in office | Austin | Full-time
$160-185k base, with founding engineer equity
Looking for a founding fullstack engineer who will work alongside me (CTO of Bomello), as a peer, to build out a product from scratch. As revenues grow, I am committed to only hiring experienced and self-starter type engineers so that we can do more with fewer people.
Agree that for a while at least it seems you'll need to understand the domain it is helping you with. That said, with the improvements in GPT4 over 3 in such a short time, and with plugins, I would be surprised if it takes any longer than a couple of years to be much much better at this to the point it is correct most of the time. You will probably still need domain knowledge at that point, not quite sure if that will last either.
To speed things up we decided to correct the ID types for the server response, which was key since they were generated from protobuf. But we kept everything using number type IDs everywhere else, even though they would actually be strings, which would not cause many issues because there ain't much reason to be doing numeric operations on an ID, except the odd sort function.
I remember the smirk on my face when I suggested it to my colleague and at the time we knew it was what made sense. It must have been one of the dumbest solutions I've ever thought of, but it allowed us to switch the type eventually to string as we changed code, instead of converting the entire repos at once. Such a Javascript memory that one :)