jadenPete
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.
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.
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.
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.
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.
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?
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.
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.
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.
Also, a side note: I dislike a lot of the popular conversation around the Baumol effect because they’re usually along the lines of “this can’t be the only reason my healthcare or education is expensive”, which is true (there are other factors at play), but the Baumol effect still explains a lot of it.
We do the work that’s too large in scope for other teams to handle, and clearly documenting and enforcing best practices is one component of that. Part of that is maintaining a comprehensive linting suite, and the other part is writing documentation and educating developers. We also maintain core libraries and APIs, so if we notice many teams are doing the same thing in different ways, we’ll sit down and figure out what we can build that’ll accommodate most use cases.
This has helped to explain why, at least for me, LLMs have been more useful for reading code than writing code. I’m also just reluctant to submit the code it’s written on my behalf without making hundreds of small adjustments, but I think I’ll need to get over that, as I wouldn’t be so nit-picky a junior engineer were completing the task.
I’ve found this helpful for evaluating new packages without cluttering my home directory. It’s especially helpful when using many packages that don’t respect the XDG Base Directory specification; they tend to dump dotfiles directly in my home directory, so keeping it clean is important.
It’s refreshing to see an editor that’s built with performance as a priority.
- Homelessness, which likely worsens mental health, increases drug usage, reduces tourism, creates a massive eyesore for everyone else, etc.
- Lack of disposable income—if folks are spending more on a rent or mortgage payment, they're not spending as much on goods and services.
- Inequality—artificially constricting the supply of housing creates a game of musical chairs, where some inevitably get left out and, because of that, can't climb up the social ladder. It also favors incumbents who already own homes or received their parents' home.
- Sprawl—zoning restrictions stifle the construction of high-density housing, which makes cities inaccessible, increases car dependence, negatively affects the environment, etc.