jadenPete

Here’s another example:

  fn f<T>() -> T {
    loop {
      println!(“Looping”);
    }
  }

This won’t compile. How do you express to the compiler that this is correct (because the function never completes) without a never type?

Rust also doesn’t support generic function types, so a callback function returning `!` is possible, whereas one accepting a type argument and returning that type is not. You could do something clever with traits, but that requires extra work.

A lot of these things are achievable without `!`, but the compiler still needs that type internally and it pieces so nicely into the type system that I don’t see the point of bending over backwards to avoid it.

Why is it bad? Implicit integer conversions are generally bad because they can produce unexpected behavior at runtime and obstruct what’s really happening, but that doesn’t seem to be what’s happening here.

Never is a standard type in many languages and is at the bottom of the type hierarchy because it’s a subtype of every type. Never isn’t implicitly converted any more than `&’a A` is “implicitly converted” into a `&’b B`, where `’a` subsumes `’b`. There’s no runtime conversion because there will never be an instance of never—it represents the value of a computation that never completes by definition.

I think what you mean to say is that implicit runtime conversions are bad, not that all subtyping is bad.

> This is patently false.

I think what they're trying to say is that housing being a good investment long-term is fundamentally incompatible with housing being affordable, and society should choose the latter. Within a given area, home values can only rise so much before:

1. New construction is permitted, thus increasing supply and lowering home values

2. Growth plateaus because demand shrinks—no one can afford homes or residents move away because property taxes become too financially burdensome

This isn't the case with all investments, or at least the growth can be sustained for much longer with other investments. A successfully run company can grow for decades before the exponential becomes unsustainable. When growth stalls, it's a lot easier to sell the stock and buy another than it is to sell one's home and move to another area.

> Moreover most home buyers do not view them as a cash flow generating asset - it’s literally their home.

I don't think this is true. Western governments have subsidized homeownership so much precisely because it's marketed as an easy way to build generational wealth. I don't think most homebuyers view their home as primarily an investment, but growth potential is definitely considered by most during the homebuying process, and homeowners as a voting block often vehemently oppose development because their investments are so precious to them.

Why does building a successful business necessitate generating economic externalities? Many do, and that should be prevented, but many also don’t. And to say that those externalities are responsible for a majority of the business’s growth in all cases is just false.

I couldn’t disagree more. Most of my company’s backend code is written in Scala, and most of our engineers dislike it because the language is difficult to understand, has way too many features, and has many ways to solve the same problem. I don’t want Rust to continue down this path, and I already worry with some of the syntactic sugar and type system additions being discussed that it already has.

A language’s type system doesn’t need to model every possible type of guarantee. It just needs to provide a type safe way to do 95% of things and force its users to conform to use the constructs it provides. Otherwise it becomes a buggy hodge podge of features that interact in poor and unpredictable ways. This is already the case in Scala; we’ve discovered almost 20 bugs in the compiler in the past year.

Apple’s hardware teams are seriously running laps around their software teams. Which is odd, because historically, it’s been the opposite.

Until iPad OS actually becomes capable for complex work and multitasking, I can’t see what the benefit of strapping such a powerful chip to an iPad is.

I'm curious, how much does this weigh? I've ridden e-bikes a few times, and it's always surprising how much heavier they are than ordinary bikes. I can't imagine how heavy this must be.

It seems like this problem (differences in how humans and LLMs use probabilistic language) and hallucination are one in the same. LLMs don’t have access to information about how confident they are, so they always choose the most likely response, even if the most likely response isn’t actually that likely. Whereas if a human is unconfident, they’ll express that instead of choosing the most likely response.

Of course, LLMs can still speak about probabilities and mimic uncertainty, but that’s likely (heh) coming from their training data on the subject matter, not their actual confidence.

Humans are interesting because they employ a two-phased approach: when we’re learning, we fake confidence (you’d never write “I don’t know” on a test unless you truly had nothing of value to say), but during inference, we communicate our confidence. Some humans suffer from underconfidence or overconfidence, but most just seem to know innately how to do this.

Can anyone who works on LLMs clarify whether my understanding is correct?

The article cites Amazon prohibiting sellers from selling their products for less on other platforms as anticompetitive behavior. I don’t doubt that this is happening, nor that it’s anticompetitive.

That being said, anyone who’s operated a two-sided marketplace knows that one of the biggest problems is consumers using your site as an index, and then seeking to dodge your fee by meeting with the seller on another platform, where they don’t have to pay it. This was a big problem for my startup.

This is a negative externality, because they’re extracting value from your platform (the list of sellers, products, prices, ratings, etc.), without paying for that value. If left unchecked, this could make running the platform financially unviable. One way to prevent this is to paywall your platform, but not every consumer wants to pay a subscription.

I think it’d be fair for Amazon to prohibit sellers advertising other platforms on its own, but prohibiting them from offering lower prices outside of Amazon outright definitely seems anticompetitive.

Then won’t foreign governments just ban freedom.gov? This problem has already been solved with networks like Tor and I2P. It seems like it would be more strategic to fund those projects instead.

I think what bugs me about EU legislation like this is how micro-targeted it is. Why apparel specifically? If waste and a disregard for the finite-ness of natural resources is the problem, why not impose a blanket, Pigovian-style tax on all extracted resources?

I got the same feeling when they mandated USB-C on Apple devices. If the problem of waste were tackled categorically, then the state wouldn’t need to get involved in matters it has no business getting involved in.

It has to stop at some point. Eventually, the regulations will become so complicated, unknowable, and unenforceable, that they’ll have no choice but to say “this is enough” and start tackling the root of the problem instead.

This question may be naive, but why is the agricultural industry so subsidized? I understand the moral argument, but why, economically, does subsidizing farms result in a more efficient allocation of resources? I've heard that it's because farming as a business is full of unpredictability, but if that were the case, wouldn't there be a significant market for private insurance, and wouldn't the cost of that insurance be priced into the cost of food?

Agreed. I don’t think easy package management is the problem, though. Rather, it’s just triggered a Cambrian explosion of packages, and now security needs to catch up.

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript.

You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, as a result, they're becoming very popular. I can pull down some code, run `cargo build`, and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community.

If you want your language/library/framework/layer in the stack to become popular, make the tooling good and make it easy for folks to get their questions answered. Everything else will follow.