ARandumGuy

Seconding this. I've been subscribed to Nebula for a couple years, as I watch a lot of video essayists on Youtube and like half of them are on Nebula. In addition to ad-free viewing, you also get:

* No in-video sponsor segments

* Exclusive videos (including some creators and series that upload primarily to Nebula)

* Early access to some videos

* Uncensored videos, as Nebula does not have the automatic content or copyright enforcement systems that Youtube has

* A decent TV app (at least on Roku), so I can watch ad-free on the TV without paying for Youtube premium

All for a much cheaper price then Youtube Premium ($60 annually vs $160, with frequent promo offers). If you already watch a lot of Youtube channels that are on Nebula, I'd highly recommend it.

I'm not sure if you realize this, but there are a lot of housing options in between suburban sprawl and high-rise apartment buldings. Like townhomes, rowhouses, duplexes, low-rise apartments, or even single family homes built more closely together.

12 Fs across 34 students is not statistically significant. Comparing the spring 2022 vs spring 2026 rates only works if the composition of the groups is similar (e.g. same % of students that previously failed the course), which seems dubious given the dramatically different sample sizes.

That doesn't mean there isn't a problem worth investigating. If I was a dean I'd certainly have some questions if I found out that 35% of students failed a class. But without knowing the specifics it's irresponsible to draw any conclusions about these 34 students with the limited data we have available.

Additionally, if someone is taking an intro class in the Spring, that's probably because they already failed it in the previous semester. While that doesn't guarantee that they'll fail again, it does make it more likely.

The main reason lithium batteries are used in cars and electronics is because they offer some of the best energy storage per kilogram. That's really important for something meant to be portable, but it's completely irrelevant for a large permanent installation.

> _However_, for the use cases that most developers or agents are looking for

What use cases are those? How did you determine that these are the use cases most developers/agents are looking for?

For me, git has a ton of features that I rarely use. But when I need them, I really need them. Any replacement that doesn't cover these edge cases is fundamentally incomplete and insufficient, even if it works fine 99% of the time.

> Sure, if you have a complete test suite for a library or CLI tool

And this is a huge "if". Having 100% test coverage does not mean you've accounted for every possible edge or corner case. Additionally, there's no guarantee that every bugfix implemented adequate test coverage to ensure the bug doesn't get reintroduced. Finally, there are plenty of poorly written tests out there that increase the test coverage without actually testing anything.

This is why any sort of big rewrite carries some level of risk. Tests certainly help mitigate this risk, but you can never be 100% sure that your big rewrite didn't introduce new problems. This is why code reviews are important, especially if the code was AI generated.

I don't know how much people outside of MN know about what's going on, but it's fucking dire here. However bad you think it is, it's worse.

> Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.

Refacoring tools (such as renaming properties) have been supported by IDEs for decades. And in Typescript specifically, the language is designed with these tools in mind, which are developed and distributed directly by the Typescript team. For all intents and purposes, IDE integration using the Typescript language server is a feature of Typescript.

And if somehow these tools don't work, the compiler will catch it immediately! This means I can refactor with confidence, knowing any type issues will be caught automatically.

It seems like you're vastly overestimating the time and effort it takes to change types in Typescript. In my experience it's something that takes basically no time and effort, and has never caused me any issues or headaches.

In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames, a process that takes like 2 seconds. You might have problems if the change exists at a service boundry, but in that case I'd just put the transformation at the service boundry, and keep everything the same internally.

> Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.

I'd argue static typing makes this much easier, because I know any input types (or output types from other components) will be enforced by the type system. So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected". The type system handles all of that, which eliminated a lot of tedious boilerplate tests.

I don't find that dynamic typing reduces the number of places I need to update stuff. It just changes when the error occurs.

If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.

IIRC Musk wanted to get an LBO, but wasn't able to find anyone willing to loan the money.

Keep in mind that a LBO is actually a good deal for the bank, because if the purchased company goes bankrupt, the bank can recoup their investment by liquidating the company.

However, that only works if there are assets to liquidate. This can include physical assets, valuable IPs, or favorable lease agreements. In other words, anything that someone else would want to purchase.

Twitter, being a website, doesn't have a whole lot of assets they could sell. Which meant that other collateral was required for Musk to secure financing.

Are there any examples where a company was purchased via a leveraged buyout and the company went on to be more profitable afterwards? Because the only examples I know of resulted in the purchased company going bankrupt fairly quickly.

Nothing Hamas has done justifies what Israel is doing to Palestinian civilians, because collective punishment is a war crime. "But they did it first" is not a valid excuse, especially when trying to excuse mass starvation and bombing population centers.