Considering this issue did also make me think - maybe the real footgun here is the async mutex. I think a better "rule" to avoid this issue might be something like, don't just use the tokio async mutex by default just because it's there and you're in an async function; instead default to a sync mutex that errors when held across awaits and think very hard about what you're really doing before you switch to the async one.
Actually I think I might be a little misguided here - confusing a mutex with an awaitable lock method versus blocking, and a mutex whose LockGuard is Send and can be held across other await points.
To clarify, I do still think it's probably wise to prefer using a mutex whose LockGuard is not Send. If you're in an async context though, it seems clearly preferable to use a mutex that lets you await on lock instead of possibly blocking. Looks like that's what that Safina gives you.
It does bring to mind the point though - does it really make sense to call all of these things Mutexes? Most Mutexes, including the one in std, seem relatively simplistic, with no provision for exactly what happens if multiple threads/tasks are waiting to acquire the lock. As if they're designed for the case of, it's probably rare to never for multiple threads to actually need this thing at once, but we have to guard against it just to be certain. The case of this resource is in high demand by a bunch of threads, we expect there to be a lot of time spent by a lot of threads waiting to get the lock, so it's actually important which lock requesters actually get the lock in what order, seems different enough that it maybe ought to have a different name and more flexibility and selection as to what algorithm is being used to control the lock order.
Assuming this quote from the article is true, it sounds like the only villain here is the school principal:
> It said the AI alert was sent to human reviewers who found no threat - but the principal missed this and contacted the school's safety team, who ultimately called the police.
So the company AI reviewers correctly determined that there was no actual gun, and the police responded appropriately to a report by a person (the school principal) who claimed to have seen this student with a gun. The question then is what the heck is this principal doing? Why do they have access to this pre-verified AI information, and why are they going off and calling the police with this information before doing any verification themselves?
Well also, none of the coverage includes what was said to the dispatcher, but maybe they screwed up too - I would expect a dispatcher to question the caller in more detail about what's going on. Like, what kind of gun was it, is it in their hand or in a pocket or what, did they point it at anyone or threaten anyone with it or are they just carrying it around, etc, and such information could be used for a more appropriate police response.
No, it's 100% appropriate. Anyone can have opinions on anything, but frankly, most of them have little relevance to reality. Their use of the word "expert" is supposed to mean the person has knowledge or expertise that renders their opinion on a subject substantially more valid and relevant than any regular person. That clearly is not the case here. If I wanted to know what a random person on the street thought about a subject, I could go ask one myself. The purpose of news organizations was supposed to be to better-inform people by getting opinions from actual relevant experts in a subject.
These people don't seem to have much ability to discuss relevant subjects like what the actual reliability of lower-tier hosting providers is, the value-add to business and iteration speed of having a variety of extra services (SQS, DynamoDB, VPC, RDS, managed K8s, etc) available, etc.
I mostly agree, though I actually wonder if the energy difference is as big as you say. Yeah the big LLM company datacenters consume tremendous amounts of power, but that's mostly for either training or serving ~millions of requests at once. I wonder what the actual net power consumption is for a single machine doing about as much work as a single ordinary person could do with just enough hardware to run the necessary models. Or what the average amount of energy for a single set of interactions is at one of the big shared datacenters - they reportedly have a lot of optimizations to fit more requests on the same hardware. I think it might be only one order of magnitude greater than a human brain. Maybe actually pretty close to equal if you compare total energy used against work being done, since the human brain needs to be kept alive all the time, but can only effectively do work for a limited part of the day.
Ruby by itself is still a pretty decent scripting language. I still think Rake is highly underrated as a command runner.
Rails is still a good web framework within its limits. If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
The lack of types may start to pinch some once you get an order of magnitude more developer-months into the app than that. Lack of overall speed, threading issues, and memory usage may be an issue once you get a few orders of magnitude more traffic. But while you're within those limits, I think you'll get features out on it faster than any other language or framework.
As they say, a lot more startups have died due to not being able to iterate fast enough in the early stages than from their traffic capacity, hosting efficiency, and bug count once they get into serious growth.
> If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
Of course lets silently ignore Github, Gitlab, Shopify and others: all small, modest complexity web apps built with Ruby on Rails. Look at Shopify last year black friday numbers and come back and tell us how Ruby is fit only for modest traffic.
I did say that those aspects of Ruby would start to be painful at that scale, not that it was totally unusable. Clearly it's usable, and there's certainly less scale-able things than Ruby on Rails out there serving big production traffic today. But I wouldn't recommend switching an app that big in some other language over to Ruby, and at least as many companies have moved off of Rails monoliths when they outgrew them, like AirBnB for example.
But would they still build with Ruby if they had to rewrite it today? It seems other commenters are saying they wouldn't. I wanted to see if it offered anything more than my python and Go preference.
For what it's worth, the last few years our we've sliced off a few custom client apps in Rails and it's felt like a great tailwind. We've been running a profitable BI app for around 15 years, but it's really hard to maintain. The dev team decided we want to rewrite it from .NET, Python, React into vanilla full-stack Rails. We were planning to rewrite it anyway to fix many old assumptions that turned out to be wrong and made maintenance a lot harder. It should also reduce the required coordination of backend API + frontend being that it's more cohesively developed together. But ultimately, we've enjoyed using an opinionated framework that has all the typical "web app" things batteries included and well-established. It helps discovery.
I think it works well for SaaS type offerings where you have a low number of high-value clients. We don't do high-traffic public sites. Perhaps my opinion would be different then.
I don't know. Do programming languages really make that big of a difference, other than with developer unhappiness and talent scarcity when hiring?
I think how many quality devs you can hire with that language is really the only question that matters 90% of the time (ballparking), so long as the language is designed for that use case, like don't use assembly to write a production webapp.
I don't know many devs that code with Ruby, I know of more devs that code in rust and Go which are newer by at least a decade? so the question of what actual benefits it has is important.
For Go, it makes it hard to mess up error handling and easy to deploy your apps since it's all a static blob, but memory footprint and optimization can be challenging at times. For rust, it takes a long time to do things, so fast shipping timelines might not be a good fit. For Ruby, does it have anything that makes it more secure, faster to code with,resilient to failure, easier to scale,etc...? I don't think anyone answered that here.
What can it do _better_ that the other languages you listed can't or can't as well?
Honestly, if you're even slightly concerned about Go's memory footprint and optimization then you shouldn't bother digging any further into Ruby.
There's a reason that the DevOps world abandoned Ruby wholesale in the late 2010s (mostly replacing it with Go).
In a world where container orchestration allowed servers to be more fully utilised, it became increasingly obvious that the ancillary tooling (think log shipping or metrics collection) often had a larger memory and CPU footprint than the core service itself.
Formerly popular tools in this class like Sensu or fluentd have either been rewritten or replaced with Go equivalents, and Ruby seems to be more or less dead for new projects outside of the Rails niche.
It's a cool and interesting type of attack, but I really don't care for the breathless clickbait headlines that are sourced to a few security researchers demonstrating an attack in a lab, that has already been patched against and has never been seen in the wild.
Mise seems pretty cool, but the thing that makes me reluctant to get on board now (current asdf user) is that it seems to want to manage too much. Especially with regard to using PATH munging.
I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing. It's to the point where I decided to give up and hard-code my PATH in my .zprofile and get rid of all of the various tools' init scripts so that I at least can clearly see and control which things are in which order and not having a bunch of scripts trying to rewrite it all the time all with slightly different algorithms.
Maybe it would work if mise could manage all "tools" (various programming languages) as well as "tools" (actual CLI applications written in one of the languages and usually installed with that languages manager, like `cargo install`, `go install`, `uv tool install`, etc), though then it seems like it might be a pain to switch over to.
> I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing.
it doesn't do this, you can even use shims with mise if you really want to
> Maybe it would work if mise could manage all "tools" (various programming languages) as well as "tools" (actual CLI applications written in one of the languages and usually installed with that languages manager, like `cargo install`, `go install`, `uv tool install`, etc), though then it seems like it might be a pain to switch over to.
Well, a regular SIM mostly just works, except for when it doesn't.
I haven't had any APN issues with regular SIMs in a while actually, but it used to be a common problem that would only sometimes auto-configure correctly. I've definitely had to google carrier APN settings and fiddle with them for a while to get text, MMS, and internet access working properly.
I also recently had an issue where I moved my US MVNO provider SIM to a new phone and it mostly worked, except for RCS. When I called them, they claimed my phone model wasn't compatible with their network, despite me already using it on their network for months. Apparently in their opinion SIMs should never actually be moved to a different phone. They offered to sell me a new phone, but I switched to a new carrier instead.
I've also had APN issues with physical SIMs, they are definitely not perfect. But I have never had an unusable "bricked" physical SIM. My eSIMs gripes are from being unable to use the eSIM at all. It's essentially a brick at that point.
RCS is a whole another kettle of fish indeed and the fact it only works with Play Integrity being on Device/Strong and the bootloader being locked is absolutely asinine to me.
Yeah but on the bright side, Google's total lack of customer service means nobody will ever be able to talk a minimum wage clerk in the middle of nowhere into transferring your phone number to somebody else without your permission.
The "abolish the police" movement did not manage to actually abolish the police, but it did drastically decrease enforcement and prosecution of crimes perceived as minor or petty, like shoplifting. Police are not eager to try to enforce the law against it when they risk getting crucified if any encounter goes wrong and the suspect is likely to be released immediately due to bail reform and get their charges dropped.
Hahahaha. The cops regularly shoot dogs and refuse to save kids. The day they worry about being "crucified" for literally any behavior at all will be a day to celebrate.
They never investigated them in the first place, my guy. Law enforcement can't manage to solve half of the murder cases in the country, let alone anything less dire.
I don't think you realize how little policing the police actually do lol
