A bit ago a semi-retired guy came back to help with some stuff including debugging serial ports. It was very cool to see him fiddle with the knobs and be like "oh those squiggles look good" "no that doesn't look right" etc. https://i.imgur.com/R5aEXbq.jpeg
Meanwhile total mystery to everyone else how to operate/interpret the machine but a lot of fun
This comment by yurishimo should not be [dead], imo
>Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.
It is true! HTML can do a lot of cool stuff, it might get you 100% of the way depending on what you're doing. But if you have a lot of forms where users pick from a value set, and want to enforce no other strings and get a good search experience, datalist does not get you there.
Thanks for the vouch! The rest of the article was indeed good but I find a lot of value in hacker news comments precisely because someone comes back to the comments and lays out why what I just read might need a different perspective. If you just want to see cool stuff that a browser can technically do, we are all capable of reading the Chrome dev blog, but we come to HN for a wider perspective. Someone telling a war story about how some little tidbit came back to bite them is also valuable (imo).
I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.
So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).
Where did I say to forgo backend validation? Of course you validate on the backend as well, but the better UX would be to prevent the user from entering a bad value to begin with, assuming it fits within your team’s performance budget.
I’m not advocating for willy-nilly package inclusion, just highlighting a current shortcoming of datalist that is often not mentioned in these sorts of articles.
(iirc if you have [showdead] on you can click on the timestamp to the comment and will get a [vouch] option as a reverse-flag, fwiw. i see it and don't have showdead enabled, so enough people have re-vouched it!)
I definitely remember seeing a post by a Chromium maintainer talking about starting development on a proof of concept implementation and surveying for semantics.
Jumping off the title and ignoring contents of post, as is customary:
look at this graph and guess which languages use each number of dependencies for their website: https://www.youtube.com/watch?v=E82ly38YEEQ&t=325s
I won't spoil the claim in the video about what the dependency number is correlated with, and I'm not even sure how true it is in general, but it's very interesting.
it is relatively new and untested irl, but interesting as gleam is very nice for fhir in some ways:
-fhir choice types imo were originally designed for some kind of object oriented polymorphism, but are nicer as sum types
-cardinality works nicely with Option for 0..1 and List for 0..*, the only ugly part is if you need primitive extensions and suddenly there are a ton of Option fields
-works with whatever http client you need for erlang or js target, meaning can use on server or in browser
hl7v2 is much uglier than fhir but commonly used eg by state immunization registries, so I am considering gleam types that have message/segment structure, but leave each field as String (as opposed to gleam fhir which uses Bool or whatever for primitive types)
after that not sure some kind of gpl toy emr probably a stripped down version of openemr that uses gleam/lustre and a fhir server instead of php, but this is definitely the mysterious step 3 ??? as there are a lot of features and integrations that take a lot of work or use different formats (hl7v2, ccda...)
For what it's worth I know you've worked on FHIR and probably know a lot of details I don't. Actually I'd be interested in talking to you about FHIR.
That said!
1) In the big picture isn't the US clearly paying more than other countries? I'm sure some of this is eg a janitor in the US costs more than a janitor elsewhere, but still...
2) Isn't the cap for the margin that insurance companies can take 20%? That is, they have to pay out 80% as claims take 20% for overhead
3) Doesn't insurance also induce more work done by everyone else who has to deal with them? So the margin the insurance company itself takes is not the only cost they add. Maybe they make providers do more paperwork, or let patients order tests etc that they would not if they were not spending other people's money, or some other reason. Say insurance pays out 80%, but 30% of documentation or actual work is not done by insurance but only exists because of them, now we're down to 56%.
I say this because literally yesterday, my wife, a pediatrician, after she spent the day seeing patients and got home to go through notes, had to leave a message with an insurance company: she saw they faxed her clinic on Saturday, when the clinic was closed, to cancel care for a patient with an ongoing chronic condition with no changes unless the insurance company got a reply in 48 hours (again, while the clinic was closed!). Now she has to schedule some kind of I don't even know what with them, to confirm the condition is the exact same, except she sees patients all day so it's a pain to schedule...
idk the fact that BCBS is a non profit and has no margin in some technical sense does not seem like a big consolation, something is rotten no?
(edit - the insurance company in the anecdote is not BCBS)
I've worked on a lot of healthcare interoperability standards, including HL7 FHIR. Those can be part of the solution in terms of making the system operate more efficiently and cutting administrative overhead. In many cases payer and provider organizations are still doing things manually that could be automated using existing standards. But they fail to do so due to lack of vision and insufficient technical resources. Literally everything that can be done with a fax can be done faster and better with X12 / NCPCP / DirectTrust standards that have been around for years and are widely supported by commercial EHRs.
It's true that no matter how you look at it, the USA spends a lot more per capita on healthcare relative to outcomes. But you have to be careful what outcome metric you look at. Like we're not doing great on life expectancy, but much of that is due to factors largely outside the healthcare system like violence, vehicle crashes, and lifestyle choices. And in other areas like 5-year cancer survival rates or new drug development we're at or near the top. Part of the problem in the USA is that we seem to be culturally incapable of admitting that rationing is needed, and that it simply isn't feasible to deliver excellent care to everyone, so political reform debates devolve into sound bites about "death panels".
The Affordable Care Act (Obamacare) set a minimum health plan medical loss ratio of 80%, or actually 85% for larger plans. And in practice most come in higher than that due to competitive pressures.
There's a huge amount of administrative overhead in dealing with health plans for things like claims and prior authorization. Much of that is imposed not so much by insurers themselves but by employers who want to hold down costs. Like a commercial insurer would be happy to sell a plan that would pay every claim immediately at 100% with no questions asked. It would be less work for them. But no one would buy it because costs would explode. Medicare and Medicaid plans also have prior authorization and peer review processes. Something like a quarter of all healthcare services are "low value care" which doesn't align with evidence-based clinical practice guidelines and may even harm the patient, so when health plans apply review processes the right way then ideally it's better for patients and holds down costs for everyone.
To be clear, I'm not here to defend commercial health insurance companies. They are part of the problem and some reforms in that area are sorely needed. But let's have an honest debate about it and stop pretending that eliminating them would solve the deeper systemic problems.
Admin inefficiencies between orgs definitely exist and maybe better interoperability and standards is the solution, but wouldn't there also be less of a problem in the first place if there were fewer different orgs all complicating workflows?
Also not saying you're wrong about many healthcare services being unnecessary or even harmful, and someone has to be the one to say no to patients asking for low value care which is definitely a real hard position to be in and a real problem. At the same time insurance companies aren't making a great case for themselves as the solution imo bring on the government death panels.
Yes, provider organizations waste a lot of resources dealing with differences between health plans. Reducing the number of different payers would certainly reduce that overhead, at least in the short term. Mandating increased health plan transparency and use of open interoperability standards can also help by allowing providers to deal with those health plans in a more consistent way and automating much of the current manual work.
In general though I'm just skeptical that a single payer solution is the best possible long-term approach. US federal and state governments are already under tremendous fiscal pressure. So if we forcibly route all healthcare payments through governments then there's going to be constant pressure to hold down costs through blunt measures. And decisions will inevitably become even more politicized with special favors or punishments given out based on party loyalty. Do we really want to put someone like Xavier Becerra or Robert F. Kennedy Jr. in charge of centrally planning something like a fifth of the US economy?
The current US healthcare system is unnecessarily wasteful and cruel. But on the positive side we produce far more innovation per capita than any other country. Let's find a way to incrementally fix the worst problems without killing the golden goose.
I am happy about even though I've never tried gram, because if zed goes to shit there will be an alternative, which hopefully pressures zed to stay sane
> I also object to making myself and my work depend on paying a subscription fee to anyone. I don't want an outage at Anthropic to affect my ability to do my work. I think it is a grave mistake to build anything on such shaky foundations as the sustainability and profit margins of the AI industry.
That’s not the premise people are building on though.
Any particular model almost doesn’t matter at this point. Harnesses are built around them. OpenAI and Anthropic are basically interchangeable in an open-source harness like OpenCode; the switching cost is virtually zero. Local models are improving rapidly and are already “good enough” for many use cases already. The bet that LLMs will continue to exist as an algorithm is pretty solid.
Oh, that's a breath of fresh air. And they are on codeberg. Nice! Thank you!
Edit: After further inspection, I think I'm jumping ship before it's too late. And I'll look, see if there's a way to lend a hand or two when I have time!
If you don't want to then fair enough :) that said if your problem is just installation, some of the gleam people realized it can be tricky and made a nice guide for various operating systems and package managers: https://gleam.run/install/
Note this includes installing erlang as well
While it is multiple steps, the frustration is a much more one time thing compared to the problems and frustrations you'd have using a language or its ecosystem for a long time or big project
Eh, idk if a totally new internet is either feasible or needed.
I also feel like if you're going to invent a new internet from first principles, how are you going to not end up with the current one? (or a shitty version of it)
The answer might be an invite tree as the article suggests. They might be hoping for too much user quality from the invite tree, or at least hoping for a level of user quality that would only work at a small scale. Rather than "zany founders, reclusive poets, eccentric engineers of all kinds, high school teachers, homegrown philosophers, garage tinkerers, and beloved drug-addled futurist artists", imo to include a lot of people a simple invite tree would get you "not a literal bot". Trying to actually evaluate user quality gets you into moderation, federation, it is not easy. You could keep it small, but that's not an Internet replacement, that's a private forum, which as the author says they already have.
Imo a good start would be the much narrow problem of identifying your device as not a bot when browsing. Something like google fraud defense https://news.ycombinator.com/item?id=48039362 except instead of a google owning your identity, some sort of user tree where you can vouch anonymously for people you know, and ban users and users who added them for scraping.
Meanwhile total mystery to everyone else how to operate/interpret the machine but a lot of fun