It became less popular a long time ago as the hype of actors as a programming paradigm died down, and then eventually akka adopted non-OSS BSL license which made many users including us switch to Pekko (a community fork) which is still developed and maintained, but again, this branch of Scala evolution is quite past its prime. Scala offers more and arguably better libraries for working with concurrency now, and even cooler stuff is on the horizon with kyo / ox / caprese.
I have been working on adding Pekko-based data pipeline into my side project, and it's an incredibly powerful system. The "bare" actors are rarely used. With streams, you can control parallelism, backpressure, add batching, retries, and so on. This is why this is so popular with systems ingesting massive amounts of data - log processing, IoT telemetry.
Which libraries are you referring to that do the same? Just curious.
I meant FP libraries like Cats Effect / FS2 / ZIO et al. – they don't really do the things that Akka / Pekko is very good at, such as multi-machine parallelism, but the conventional wisdom nowadays seems to be that it's easier to start with those libraries and progress to Pekko if you ever need that, rather than architect the system with Pekko from the start when you don't need its power.
I don't know if I personally agree with that, I've had a better experience with Akka (even raw actors) than with FP libraries, but what I mentioned is definitely the general vibe in the publicly active part of the community that's I'm observing. We gotta keep in mind that there are lots of companies and devs that never talk about what they're doing in public, so of course my perception is biased by that.
My own expertise is shifting more and more to the frontend / Scala.js these days, so please forgive/correct any inaccuracies.
The assumption that Cats Effect / FS2 / ZIO is easier than Akka / Pekko is questionable. There's the assumption that the Akka ecosystem requires the entire system to be built using the various features the ecosystem offers, when in reality it easily scales down to simple microservices just as well, if that's the only option or the overall preference.
One reason to reach for the pure functional libraries is a desire to avoid some of the many footguns Akka / Pekko has. For a long time, using Akka meant not being able to rely on the Scala type system for checking messages sent between actors, and for the people attracted to Scala due to the advanced type system, this was a deal-breaking drawback.
All in all, the FP libraries and the actor system libraries are almost direct opposite approaches to problem solving.
Well, Akka/Pekko is typed now. There is a learning curve to Akka, but it took me 3-4 weeks to get my system working. I can't imagine doing it with pure FP, it would break my brains.
As someone said - these are very cool but niche capabilities that companies do not talk about. It's almost like a secret weapon in the sea of over-engineering and hype.
Scala has been very enjoyable and productive for me and the teams I've worked on. The first couple years of v2 -> v3 transition were a bit rough as the tooling and ecosystem was catching up, but now we happily use Scala 3 with no looking back. The language and ecosystem are evolving in a good direction, and I'm happy to play a small part in that with my open source libraries for Scala.js (which is the entire reason I got into Scala in the first place – so much simpler and safer than Typescript).
Scala is perhaps not going to replace Java in every old enterprise, but in my personal experience working for startups, it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code. Finance, health systems, etc. And yet it's also ergonomic and pleasant enough for me to eagerly use it in my non-mission-critical personal projects as well.
> it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code.
How much of this would be due to actual language features, and how much due to selection bias induced by talented and ambitious software developers looking into functional programming languages as a means to satisfy their intellectual appetite?
I've worked both at a startup that used functional programming libraries pretty heavily, and a startup that is using as plain of a Scala as you can imagine (no cats / zios / kyos / etc. in sight), and both benefited greatly from Scala language itself. The rich, safe and sound type system, combined with ergonomic syntax and well thought out features make it very easy to both read and write code – and most importantly – to make massive changes with very high confidence – which is an absolute necessity in a fast moving startup where the business requirements evolve all the time, features are shipped urgently with some tech debt that needs to be effectively addressed later, etc.
In terms of talent there is definitely some self-selection as with any non-default tech stack. Scala is a sharp tool and there are both people who are attracted to it for the pragmatic utility of its sharpness, and people who are attracted to it for wanting to play with sharp things. Both types are smart but the latter group have given Scala a bad rep in the past for being too smart and thus writing code that was too clever for others to understand. But nowadays the general vibe in the talent pool is a lot more pragmatic.
> I've worked both at a startup that used functional programming libraries pretty heavily, and a startup that is using as plain of a Scala as you can imagine (no cats / zios / kyos / etc. in sight), and both benefited greatly from Scala language itself.
Wouldn't you want to use Kotlin for the latter these days? It seems to have broadly wider adoption than any "plain" variety of Scala.
I don't know, kotlin has its pros, and is absolutely here to stay due to Android alone, but I always felt it being more or less just syntactic sugar for Java 8, to the point that now even Java has some more advanced/elegant features, like proper pattern matching with algebraic data types, while Kotlin is stuck with dumb sugar for instanceof checks.
Scala was always much more elegant and actually going the extra mile.
Kotlin's adoption is not that much bigger than Scala, and it's no good to me, as it's heavily concentrated in the Android world, which is irrelevant to me. Among other things, that means that Kotlin.js is not as good as Scala.js, both itself and in terms of the ecosystem – and the quality of Scala.js is half the reason I'm using Scala in the first place.
Kotlin as a language is also closer to Java on the Haskell <---> Scala <---> Java spectrum. We just don't want to move in either direction on that spectrum, Scala sits perfectly where it makes sense to us.
It's interesting that some people here are saying that Java's recent improvements will eat into Scala's market, when actually, it seems that it will eat into Kotlin first.
I've had a (relatively) bad time with Scala codebases. The last one I was involved in was like a 6-minute wait between making a code-change and being able to run or test it. But I still wanna work with Scala devs.
I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase.
It's not about intellectual appetite though. It's about not re-litigating the same crap at every new work place. Avoid mutability and nulls where possible, etc.
The problem is that it is easy to write code that is not easy to read/understand afterwards. Especially if the code has a lot of operator soup and implicits.
Do people still do that? I thought that the whole "you can just google goobedygook" meme died already! ZIO for this reason has sane normal proper names for things for example.
Scala is not just a good functional programming language. It's also possibly the best OOP language around. The magic happens when these two aspects are combined.
This has been my personal discovery as well. I inherited a bunch of old Scala code and, having had no experience with Scala, it took a while to get up to speed.
We built full stack web applications: Scala on the JVM on the backend, and Scala.js on the frontend. For the frontend, used React.js (via Scala.js bindings) at one company, and my own Scala.js UI library Laminar at another. Mobile was implemented as a responsive web app. I've read that you can even use React Native from Scala.js, but we haven't needed that, so I haven't tried. The older React.js bindings were somewhat cumbersome, but the newer ones (slinky.dev) were great. The rest worked very well.
Working in a single language across frontend and backend is amazing, especially when the language is so nice. Sharing models, codecs, validations, etc. And again – all of that in a very friendly language. Scala's expressive yet safe type system is very good at describing the business domain, encoding constraints, etc.
The only weakness of Scala.js I would say is it takes a bit more effort to integrate with JS libs. The mechanism is the same as with Typescript – just need the type definitions, but in practice it needs a bit of manual work. It's not a big deal though because with Scala.js you don't really do the 200-npm-dependencies thing that so many JS projects are cursed with. Lots of stuff comes with the language or from nice Scala libraries, including immutable data structures, powerful collections, validations, state management, etc.
Scala has somewhat of a reputation for being complex, but the language itself is ecstatic in its simplicity and elegance. The problem historically lied in certain functional programming libraries that require a certain formal / academic mindset to work with. They did become more ergonomic and better documented with time, but those are still very advanced concepts for most devs. I did work with such a codebase, and I have to admit it was not the easiest. But that was before AI – nowadays it's a lot easier for me to figure out these things. But I don't need to, at my current job we don't use them. So I would advise to learn Scala the language before going off the deep end into hardcore FP libraries. That's a completely optional destination that you don't need to force onto yourself if that kind of style doesn't jive with you.
Speaking of AI, I've been asking both ChatGPT and more recently Claude about Scala 3 and about functional programming libraries, and they're pretty good. I don't "vibe code" so don't know about that, just asking for code snippets or for explanations.
I think a lot of criticism of Scala comes from the functional paradigm. More specifically it’s trying to be a mainstream language when the concepts it represents are not quite mainstream concepts for most software. The language designers, in an attempt to make it more mainstream, allow devs to use Scala in the more mainstream way (object oriented). This flexibility, ultimately, perhaps strangely, appears to hurt its adoption because of the learning curve of dealing with a language that mixes the two concepts.
Also for me, subjectively, it honestly feels too abstract at times. You can almost feel the academic joy of the beautiful, unintelligible concepts where you can express things so succinctly, but requires a small mountain of concepts to understand how to write that nice code. It’s quite frustrating to do battle with the compiler when you don’t fully understand the type system and that initial hurdle is kind of tough to get over if you’re also trying to switch into a functional paradigm from an objected oriented one.
The problem with overly abstract concepts is a problem of specific Scala functional programming libraries, and not of the Scala language itself, or of other, simpler Scala libraries (e.g. com-lihaoyi stuff, Play, my own Laminar on the frontend, etc.)
If you need to know category theory concepts like Monad / Semigroup / etc. in order to understand your code, you're not doing regular Scala, you're doing Haskell-style FP in Scala. Which is a popular choice that many people swear by, but is entirely optional. Personally I don't think the complexity of that approach is worth it, and we don't use any of that stuff at work, and still reap the benefits of Scala.
Scala is a true multi-paradigm language, it does not have a monoculture. Lots of people who use Scala don't use highly abstract FP libraries. I very much don't think that the OOP side of Scala is the language designers' concession for the sake of broad appeal. Seamless fusion of FP and OOP is the essence of Scala, and it works great for that without any third party libraries. The designers' attitude is evidenced by the libraries created by their companies (e.g. Play, Akka) and by the learning materials, both of which lean heavily on plain Scala without going off the deep end with FP libs.
> If you need to know category theory concepts like Monad / Semigroup / etc. in order to understand your code, you're not doing regular Scala, you're doing Haskell-style FP in Scala
FWIW, "Semigroup" is not a "Haskell concept" either. Equally, it's a facet of specific Haskell functional programming libraries, and not Haskell itself. Granted, Monad is baked into the language (as do notation).
> I think a lot of criticism of Scala comes from the functional paradigm.
Which functional paradigm. There are at least two in common usage in the Scala community. Odersky's vision was an ML style FP. And now ML patterns are common in modern PLs.
Java will never "catch up" to Scala (for example, the type system / generics will not evolve in the foreseeable future).
But once Valhalla lands, with some additional JEPs, Java will be very close to the core of what Scala offers. Where there are gaps, some of these can be filled via libraries (think immutables.org, or others providing persistent data structures).
As a matter of fact, these days at most companies that I see the typical deployment model is "micro"services, which you can quickly develop via Spring Boot or the alternatives. No need for ultra complex code or asbtractions, Java does it just fine. And you have all the tooling you need for the enterprise world.
I think Scala is an excellent language for teaching ML-style programming. I would still recommend it for that purpose. But there is no longer a killer app or need for Scala, that would convince most people to use it for new projects.
Just like Scala by virtue of being a guest language on the JVM ecosystem, never will replace Java on the minds of JVM architects.
Kotlin has an advantage here, because ART nowadays is effectly KVM from Google's point of view, where they grudgingly update Java support to keep up with Maven central.
Scala has nothing like this, and the update on Python alongside native libraries, kind of stole its demand in big data, hence why this kind of scenarios is described on the article.
They're not in the same playground. Scala has a far more advanced type system - more close in power to Typescript or Rust than Java - and capabilities like compile time metaprogramming which aren't on the Java roadmap. Or more mundane things like immutable collections or a copy method for "record" classes.
Whether that's an advantage in day to day business development is a different question.
Yes, Java has been getting a lot of features Scala has had since (more or less) always. But it's a continuing process, and not all such features are yet fully fleshed out and polished in Java.
Also, Java will probably never get many of important features Scala has (or will have). It may not be some esoteric things, like higher-kinded types. But things like meta-programming/macros. Or features which may be advanced from theoretical point of view, but are actually easy from user point of view (because they lead to a simpler code), like Capture Catching.
If capabilities (Capture Catching) proves to be very useful (and really solves the problems it claims to be able to solve) then it's likely that Java will also implement it, no? So... in about 8-15 years?
I doubt it. For Capture Catching of Capabilities to work, you need some of the unique sauce practically only Scala has. E.g. Contextual functions or path-dependent types. Java almost certainly won't adopt these.
That does not make sense... In November, her visa was revoked at the border, when trying to enter the US. At that point, she was obviously turned around back into Canada. Then later, she was detained when trying to enter the US from Mexico in 2025.
So, how do you suggest she managed to enter the US after November in order to have remained there illegally? Did the CBP, who have just revoked her visa a few days/weeks prior, just let her in on a tourist visa? That does not sound very believable, even for the previous US administration.
And what do you suggest her plan was? Previously she was on TN work visa. You seem to think that after having her TN visa revoked, she managed to get into the US on a 90-day tourist visa instead (thus working there illegally), which is why she needed to run for the border after 3 months, and why she was detained when trying to re-enter. But what kind of plan is that – to run for the border every 90 days after having your TN visa revoked. That is such an obvious recipe for failure, nobody who employs an immigration lawyer – like that lady – would have gone ahead with it.
I've definitely seen other headlines overselling similar detention stories for rage bait, but I don't see much wiggle room in this case.
> This is why I have doubts about self driving cars, it changes the accountability from the driver to the manufacturer. And I have a hard time believing the manufacturer would want that liability, no matter how well they sold.
Under current laws, perhaps. But you can always change the laws to redirect or even remove liability.
For example, in BC, we recently switched to "no-fault insurance", which is really a no-fault legal framework for traffic accidents. For example, if you are rear-ended, you can not sue the driver who hit you, or anyone for that matter. The government will take care of your injuries (on paper, but people's experiences vary), pay you a small amount of compensation, and that's it. The driver who hit you will have no liability at all, aside from somewhat increased insurance premiums. The government-run insurance company everyone has to buy from won't have any liability either, aside from what I mentioned above. You will get what little they are required to provide you, but you can't sue them for damages beyond that.
At least, you may still be able to sue if the driver has committed a criminal offence (e.g. impaired driving).
This drastic change was brought upon for us to save, on average, a few hundred dollars per year in car insurance fees. So now we pay slightly less, but the only insurance we can buy won't come close to making us whole, and we are legally prevented from seeking any other recourse, even for life-altering injuries or death.
So, rest assured, if manufacturers' liability becomes a serious concern, it will be dealt with, one way or another. Bigger changes have happened for smaller reasons.
>So now [...] the only insurance we can buy won't come close to making us whole
"So"? I don't see what one thing has to do with the other. Why would a lack of liability imply an insurance that doesn't fully compensate a claim? It's not a given, for example for insurance against natural events.
EDIT: Sorry, I think I misread your question. Let me answer it more directly:
Driver insurance in BC is offered by ICBC, a "crown corporation", i.e. a monopoly run by the government. You have to buy this insurance to drive in BC. This insurance gives you some benefits (healthcare and some small compensation) in case you get in an accident. As a matter of fact, those benefits are often not enough to make you whole. They pay much less for pain and suffering, loss of income, etc. than a court would grant you if you could sue. But – you can't sue anymore. So, who is there to make sure that the government-run insurance monopoly will make you whole? Nobody. Because you don't have the legal right to be made whole anymore. And since there are no checks on the government, the government does not pay enough. Because, why would they, if they don't have to? They only have to pay you as much as their policy says they should pay you. You can not challenge the policy on the basis that it does not make you whole, because you don't have the right to be made whole anymore.
--- Original comment:
Natural events are nobody's fault, that's why you aren't made whole, that's why you can't sue anyone for them, with or without insurance. [ETA: you can only sue your private insurance company for what they promised you, which may or may not make you whole, depending on coverage].
BC government made the "idiot rear ending you" scenario into a "natural event", so to speak, so that you can't sue the idiot, or their insurance, or anyone, to recover damages. You will only get what the government-run insurance monopoly will give you, which is not much.
This isn't directly about insurance. This is about the government declaring that liability for most traffic accidents does not exist anymore. Which is the part that is relevant to this conversation. If liability can be extinguished wholesale for all drivers like this, then this can surely be done for self-driving cars. Not saying that it's a good idea, just that this option is on the table.
The old system was horrible though, you had to sue to get compensation, and could get sued for a fender-bender. The old system was _great_ for lawyers.
In the old system, you only had to sue for compensation if / when the government wasn't offering you what you were due. It was entirely the government's choice to drag so many cases through the courts instead of paying. But at least the judicial system eventually made you whole, if you were able to navigate it. If the government cared about us so much that they wanted to fix the system, they could have simply chosen to pay what was due from the start, saving everyone the time and the legal expenses. But they didn't.
Fraud was another concern. Huge payouts from parking lot whiplash were indeed not uncommon, with the help of lawyers. However, I fail to see how the new system was the best solution for that. They went from one extreme, where fraud was rampant, to another extreme, where we have no rights. At least the first extreme cost us only a few hundred bucks per year on average. The new extreme saves you a bit of money but leaves people injured for life with no meaningful compensation for the harm done to them.
Kind of beside the point though, regarding self-driving cars.
Clearly, eh? Spoken like someone who didn't get debilitating whiplash for years from being rear ended on a highway. My friend's vestibular system has been shot for 8 years and counting from that accident, and she still can't drive / bike / do much requiring balance/hand-eye coordination anymore. She was "lucky" this accident happened under the old system, she will at least get compensation ("will", because it's only now getting to trial, because the government insurance wouldn't pay what is due on its own, and the same government wouldn't fund the courts to provide a speedier resolution). If this accident happened today, she would have gotten peanuts that aren't enough to even offset the increased costs of life, let alone get any meaningful compensation for pain and suffering.
Do you want to tell me more about how you saving ~$500/year outweighs people like her being absolutely shafted under the new system? Please don't, I don't care. That's not why I commented.
The main purpose of my original comment wasn't to say that the new ICBC system is shitty – enough was said about that elsewhere already. It was to illustrate with a real life example that laws regarding liability can and are changed in very significant ways when the situation calls for it. Petty political reasons being as good a call as any, apparently, so I'm not worried about self-driving cars being stiffled by that. There's a sprinkle of "be careful what you wish for" in there as well, for those who see manufacturers' liability as a problem.
You could spend the rest of your life, writing anecdotes and stories, but how it will be meaningful in determining the net sum of upsides and downsides…?
That's an interesting, well sourced article, I'm glad I've read it. I honestly didn't know that the full-size straw-airplanes were fakes from a movie. They're the face of this metaphor.
That said, the article would have been a lot better without moralizing about harmful colonialism, or claiming that this metaphor is supposedly an insult.
The purpose of this metaphor was never to gain historical insights, or to teach a lesson about colonialism, or to judge the Polynesian natives from 80 years ago, it's to teach a lesson about modern practices of software development (or science I guess). It's a fable.
You can replace the Polynesians in the fable with anyone else, and the payload of the fable does not change. Because the payload of it has nothing to do with the Polynesians. I personally didn't remember that this metaphor was specifically about Polynesians and the war supplies. I remembered it being about some abstract tribes, possibly Africans and humanitarian aid supplies. Did someone explain it to me the wrong way, or was it me who assumed wrong from the fake photos? I dunno. It does not matter. I wasn't relying on this fable for anything other than a software development lesson. It was not a covert tool to justify colonialism, or to assert intellectual superiority over some historical tribes on the other side of the globe.
It's definitely good to know the historical truth – as I said, I genuinely do appreciate all the exposition in this article. But, if you package that together with the moralizing, it comes off as yet more culture war BS that I am so sick of.
The difference in motivation is very important. If you write with the primary goal to expose historical inaccuracies – that's great. Then I can trust you. But if you write with the primary goal to stop people from using offensive (in your view) metaphors, then the historical inaccuracies are just a convenient tool, a talking point, for you to achieve your real goal. Because if this metaphor was actually historically true, you would probably still find it offensive. And so if that's your goal, then I can't trust you to provide historical accuracy. I will suspect you of presenting selective evidence, and other tricks to further your goal. That is why your moralizing detracts from the article.
Welp, unfortunately it's too late to fix my comment.
I didn't mix them up on purpose, and I won't pretend to be an expert on the taxonomy of the various Pacific Islander ethnicities.
Yes, the article does mention Melanesians by name. So what. It mentions other important things and people by name that I don't remember either. So what. Those exact names and identities are not important, neither to my point, nor to the point the article is making.
I think it is strongly indicative that your underlying bias so colored your reading of the article that you made a very basic factual error. I would encourage you to read it again with a more open mind.
It wasn't any more "rude" than repeatedly throwing vague insults and insinuations at me without providing the real reason. But I don't see you caring about that. We both know why. Because "rudeness" is not your real concern, your real concern is the same as the other culture warrior, and you're avoiding stating it directly for the same reasons – it's entirely unfounded and indefensible. So instead you go with vague nastyness that you think could be mistaken for something profound and is therefore above criticism (it can't, and it isn't).
If by any chance that is not what you meant to come off as, you may want to reconsider low-effort passive aggressive one liners as your communication medium.
On the contrary, I'd say it proves their point. They don't know or care whether it's about Polynesians or Melanesians (and I don't think you care either - would you have considered their comment fine if they'd named the correct group of people?). It doesn't matter.
You’re dead wrong, I do care. It does matter. I disagree with the comment but I would not have responded this way if it hadn’t made such a blatant factual error. If we’re going to make assumptions about the internal mental state of other commenters, would you have said the same thing if he misidentified, say, Germans for French? I don’t think you would have.
> would you have said the same thing if he misidentified, say, Germans for French?
In a context like this? Yes. I struggle to think of a phrase that bears the same relation to France or Germany, but can't think I'd care more. (I think I heard once that the "let them eat cake" princess was actually in Spain rather than France? But no-one cares)
Just saying "speculation" doesn't really paint the picture of what's going on. In 2010-s everyone here blamed foreign speculators hiding in the shadows, but we live in a different, worse, world now.
This country's housing and immigration & temp. resident policies are absolutely out of sync, intentionally. In 2021 they've changed the rules to add hundreds of thousands of people overnight, but did not build anywhere close to the corresponding amount of housing. Then they did it next year again, and again, and again, and they're still doing it, and the next government plans to continue doing it.
This isn't mere speculation. This is deliberate policy to manufacture a housing crisis. To not only keep the pre-existing crisis going, but to deliberately and methodically escalate it. Politicians profit both from their own investment properties and from bribes (ahem campaign contributions, speaking fees, board positions, ...) paid to them by all kinds of businesses who profit from oversupply of labour and undersupply of housing.
"Speculation" implies taking significant risk, often in an under-regulated market. But the current situation is nothing like that – there is barely any risk, when both the supply (zoning & construction) and demand (population growth) sides of the market are heavily regulated with the intent to raise prices. Capital is all you need to reap the profits, pretty much.
Asking as someone not that familiar with Canadian politics, is this "the next government" as in the Liberal one that would replace Trudeau after his resignation, or the (likely) Conservative one that would be in power after the general election?
The latter. Conservatives have shown no serious interest in reducing immigration. Their politicians get all the same profits from the crisis, plus the votes of socially conservative immigrants on top. Canadian politics is full of weird alliances.
> That puts paramotoring in the same safety category as hang gliding and base jumping in my mind.
Base jumping is NOT in the same category as the other two. It is riskier by one or two (or more) orders of magnitude, depending on how you count.
> I.e. it is far too dangerous an activity to be doing regularly.
That is not how risk works in paramotoring / paragliding / hang gliding. Doing it regularly means you're more "current" – less likely to make bad decisions, due to regularly exercising pilot skills. This more than offsets the increased risk from increased number of flights.
Paramotoring, like paragliding and hang gliding, can be extremely safe – with proper skills, weather conditions, and equipment. Accidents usually happen when people decide to go beyond safe conditions, e.g. fly in too thermic / too windy conditions.
Something to keep in mind is that paramotors are the easiest way to fly. And the easiest option always attracts the kind of people who look to expend the minimum amount of effort to get what they want. This attitude, predictably, results in more accidents – for this particular subgroup, not for all paramotor pilots.
In these sports, the pilots rely on their self discipline to stay safe. This is the real reason why these sports can never go mainstream – the actual skills are easy to learn, but the discipline is not.
> in time it does work out largely in that direction
To be fair, that's usually thanks to government interventions and regulations, not thanks to free market staying free.
Markets fail for very known, very well described reasons. When they do, they rarely recover on their own, and the abusive rent seekers only become more entrenched with time (again, in the absence of regulations to curb that).
In this startup community we see a lot of "disruption" (free-market-success) stories, but in the broader world, things don't usually work out that way, and when they do, it's often just to replace one rent seeker with another.
Definitely, my intent wasn’t to hand wave away the role government plays there. The lag that is inherent in some regulatory departments though seems too long and it’s the working class that suffers to most. I think FAA and NASA are good examples of largely well-run departments while the SEC, EPA, and FDA appear to be largely a sham who really let corporations get away with literal murder to the detriment of the greater good. Things have to get extremely bad before they are able to do anything perhaps because their authority is stripped.
https://www.youtube.com/@rockthejvm
https://rockthejvm.com/
Great videos.