We recently started using DBOS for durable execution - it's much easier to integrate than Temporal and it Just Uses Postgres(tm), which is nice.
Readit Newsdminor commented on How to think about durable execution hatchet.run/blog/durable-... · Posted by u/abelanger
dminor commented on I tried Gleam for Advent of Code blog.tymscar.com/posts/gl... · Posted by u/tymscar
Gleam is a great language. It didn't click for me when I was trying it out, but I'm glad to see more people enjoying it.
And I wonder if Gleam + Lustre could become the new Elm.
I looked at lustre for a recent project and it seems very nice. But the ecosystem is pretty small yet (I could find no examples of auth, for one), so I ended up going with liveview.
I'm hoping it succeeds and gets bigger because I really like its ergonomics.
dminor commented on Europe converged rapidly on the United States before stagnating constitutionofinnovation.... · Posted by u/tbs1980
It always amazes me that some Europeans look to the USA as some goal to aspire to. As an American, all I’m trying to do is get rich enough to move to Europe someday. There are greater goals than growth at all costs. Things like respecting the humans that live there and putting their well-being above corporations. If that thwarts “growth”, so be it.
You don't have to be rich to move to Europe. The cost of living in most European countries is less than the USA (which you would expect, given their lower salaries).
dminor commented on Why America's economy is soaring ahead of its rivals ft.com/content/1201f834-6... · Posted by u/kvee
This is what I’m trying to figure out. Medicare is kind of an advantage, but your out of pocket medical expenses in Thailand aren’t that bad unless you get cancer or something, then you just relocate back? American basic healthcare prices are just really messed up, so your insurance doesn’t really pay off until something serious happens.
I don't know about Thailand, but in France you can apply to join their healthcare system after 3 months. In the meantime you must have private insurance but it's a fraction of what it is here.
dminor commented on Australia starts peanut allergy treatment for babies bbc.com/news/articles/c0x... · Posted by u/peutetre
dminor commented on Australia starts peanut allergy treatment for babies bbc.com/news/articles/c0x... · Posted by u/peutetre
We asked about swim lessons and were told avoidance is the best way to prevent drowning.
Swim lessons don't require you to swim every day for the rest of your life
dminor commented on Australia starts peanut allergy treatment for babies bbc.com/news/articles/c0x... · Posted by u/peutetre
Our son is very allergic to peanuts and less so to cashew, and sesame. We went through oral immunotherapy and it's been absolutely life changing. He used to need an epi pen in case of chance encounter, but now he eats 2 whole peanut m&ms every day to keep his dosage up. It's been difficult finding an allergist in Germany that's willing to accept this and move forward
Obviously everyone's mileage will vary, but I'm happy to see this treatment being more widely adopted
I asked our allergist about oral immunotherapy for my daughter and he cited a study that found that avoidance was more effective in preventing severe reactions.
Fossil is really interesting and Mercurial is probably one of the better git competing version control tools, but git is too ingrained to be replaced.
The only thing that I can see ever replace git is something that is fully backwards compatible with git and insanely intuitive and possibly extents git or replaces it, but again key thing would be 100% support for regular git repositories, if people enjoy using it with existing git codebases thats step 1. Im not sure if anybody is even trying to engineer such a thing, and lets say they have 100% backwards compatibility with git, what would you change about it to migrate into? Do you keep the same exact underlying git but the commands are more ergonomic somehow? Or are there alternative approaches to how git stores code that could be more efficient somehow?
It takes someone making something better but also compatible with the dominant offering.
Sidenote I had a coworker who worked with people using SVN but he kept a git branch still so he could more easily revert code and experiment, I forget his approach but it seemed to work. I assume the repo from git was a layer above the SVN directory maybe. This goes back to what I am saying though, even though its a little different he was able to still satisfy the needs of the client with their tooling but still use tooling that hes productive on.
Jujutsu is along the lines of what you describe: https://github.com/martinvonz/jj
You can drop it in and work seamlessly from git repos
dminor commented on The hater's guide to Kubernetes paulbutler.org/2024/the-h... · Posted by u/paulgb
There were some "hype cycles" (in Gartner's lingo) that I avoided during my career. The first one was the MongoDB/NoSQL hype - "Let's use NoSQL for everything!" trend. I tried it in a medium sized project and burnt my finger and it was right around when HN was flooded with full of "Why we migrated to MongoDB" stories.
The next one was Microservices. Everyone was doing something with microservices and I was just on a good 'ole Ruby on Rails monolith. Again, the HN stories came and went "Why we broke down our simple CRUD app into 534 microservices".
The final one was Kubernetes. I was a Cloud consultant in my past life and had to work with a lot of my peers who had the freedom to deploy In any architecture they saw fit. A bunch of them were on Kubernetes and I was just on a standard Compute VM for my clients.
We had a requirement from our management that all of us had to take some certification courses so they would be easily to pitch to clients. So, I prepped for one and read about Kubernetes and tried deploying a bunch of applications only to realize it was a very complex piece of moving parts - unnecessarily I may add. I was never able to understand why this was pushed on as normal. It made my decision to not use it only stronger.
Over the course of the 5 year journey, my peers' apps would randomly fail and they would be sometimes pulled over the weekends to push fixes to avert the P1 situation whilst I would be casually chilling in a bar with my friends. My compute engine VM, till date, to its credit has only had one P1 situation yet. And that was because the client forgot to renew their domain name.
Out of all the 3 hype cycles that I avoided in my career, the Kubernetes is the one I really am thankful of evading the most. This sort of complexity should not be normalised. I know this maybe unpopular opinion on HN, but I am willing to bite the bullet and save my time and my clients' money. So, thanks for the hater's guide. But, I prefer to remain one. I'd rather call a spade one.
Early on in the container hype cycle we decided to convert some of our services from VMs to ECS. It was easy to manage and the container build times were so much better than AMI build times.
Some time down the road we got acquired, and the company that acquired us ran their services in their own Kubernetes cluster.
When we were talking with their two person devops team about our architecture, I explained that we deployed some of our services on ECS. "Have you ever used it?" I asked them.
"No, thank goodness" one of them said jokingly.
By this time it was clear that Kubernetes had won and AWS was planning its managed Kubernetes offering. I assumed that after I became familiar with Kubernetes I'd feel the same way.
After a few months though it became clear that all these guys did was babysit their Kubernetes cluster. Upgrading it was a routine chore and every crisis they faced was related to some problem with the cluster.
Meanwhile our ECS deploys continued to be relatively hassle free. We didn't even have a devops team.
I grew to understand that managing Kubernetes was fun for them, despite the fact that it was overkill for their situation. They had architected for scale that didn't exist.
I felt much better about having chosen a technology that didn't "win".
At first glance it looks more complicated than DBOS, not easier. DBOS is just a library and doesn't require a special DSL.
Also we use node which it Little horse doesn't seem to support.