steveklabnik

Miri is a runtime thing so it can’t be in the compiler.

The compiler could interpret all unsafe via it but then it would be very slow, defeating the point.

This is the way the Rooney family manages the Steelers. They stick with coaches for a long time. They've only had four coaches in the last 57 years!

I was kinda shocked when he was let go, to be honest.

Same!

Microsoft has invested in Rust for a very long time, and uses it themselves in production. I really doubt they are trying to get Rust folks to move to C#.

The standard is more like Sinatra than Rails.

Topcoat is very cool though, and there’s a few others in this space too, like Loco. So maybe we’ll see folks move to something more batteries included.

Usually people say “spatial” vs “temporal”.

It’s actually the opposite: the language has zero allocations in it. Allocation is entirely a library concern.

When you want to have a closure allocate an environment, the closure itself does not: the Box you wrap it in, which is a stdlib type, does.

Some of mine are and some of mine aren’t, but the ones that are are on platforms that are still made and supported, unlike Intel Macs.

I didn’t say they didn’t exist. I said it isn’t bizarre that a startup does not prioritize support for unpurchasable hardware that is no longer supported by its manufacturer.

If panics are set to unwind, you do need to consider it, and the UnwindSafe auto trait is there to help with memory safety, but logical issues can still arise.

It’s way way more rare in Rust though.

Intel Macs haven't been sold for over three years now. I don't think that's bizzare.

Origin is a platform, this is about storing context in your repository directly.

> To the extent of considering other choices "immoral".

This is literally an /r/pcj meme.

> and, of course, not much can be extrapolated from any benchmark

Right, so one case (which I certainly believe is possible) is very different from “time and time again.”

I’m curious where you have seen this.

The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that.

Many people have decided that this decision supposedly specifically about licensing ideology.

You can make up your mind about which of the two you believe.

See also, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948

Certainly meant to be more of a teaser. We’ll get there.

It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. But there’s just a lot of stuff that’s already working in existing systems that just hasn’t been productized because those companies aren’t trying to get into the version control business.

If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. We think that workflow is very valuable for people.

We certainly know that people will want to know more details before they buy, and have shared stuff with prospective customers during the POC process. We’ll be more generally open about it over time.

We are huge believers in stacked diffs, both for humans and machines. That said, everyone is trying to figure out what code review means in this new world, so we're open to things changing here.

You can get claude to produce small, focused stacks, rather than 10,000 line monstrosities.

It's certainly not the case that no open source projects use monorepos, you are right that the BSDs do as well.

It's that those repositories are still orders of magnitude smaller than the ones that are inside of companies. Monorepos tend to be larger than polyrepos, due to the fact that you've got everything all in one repo, but that doesn't mean all monorepos must be truly large.

The real issue with the open vs closed bit is that features like "this subdirectory of the repository is only writable (or even visible!) to some people" is basically nonsense for open source, but valuable to a company monorepo. Their needs are just different.

I found this reply very confusing... is this an atproto joke?

Trying to keep it high level here. Explaining this is important, but it's just an entirely different kind of post. That post would be deep in the weeds, and this one is at a high level. Both matter, for sure. And we'll put out more technical posts as time goes on. But since we don't really have much on our blog just yet, we're starting with more abstractt stuff.

Thanks Rick!

I realize this post is light on technical details. I expected this kind of reaction from HN, which is also fine. The goal here is more to share anything about what it is that we've been doing; a lot of people assumed that we were going to be coming out with a GitHub-style social coding forge for open source, and so on some level, this is us saying we're not going to be doing that. A lot of people also assumed we'd be focusing purely on jj, and so we wanted to make sure to talk about how we do care about git compatibility, even as we look to the future.

We'll be talking more about things as time goes on, but rather than never posting anything, this is the start of us stretching our muscles and being more involved in the public conversation around the future of version control. We've been too quiet!

Sort of! It's not that we're against general purpose protocols, it's just that they need to be fit for purpose. For folks for whom the git protocol works for them, we're happy to support it. We just need more than that.

And yeah, we're not dependent on git-the-codebase at all.

For whatever it's worth, I read zero negativity about Rust in the title or content.

I don't know enough about the details to speak to it.

You can use a "subtype predicate" for this: https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...

This is called "pattern types" in Rust land, as your parent mentioned, and is exactly the kind of work being talked about.

NonZero isn't a hack: it's an example of a common pattern. If pattern types were available today, you'd still want NonZero, as an example of a pretty standard pattern.

The idea is, as always: prove out the specific version, then generalize.

> As you can see, it has many convenience methods to make it easy to work with, compensating for the loss of the Rust enum.

Also, Rust does try to do some of these optimizations itself. These aren't exposed in the stable language to let you do some more advanced things, but it wouldn't be impossible for you to get the best of both worlds by letting you communicate this stuff more directly to the compiler. Right now those things are more like "this value is where you should put the tag" than the more advanced stuff here, though. Would be cool to see someday!

Pretty much all of Nathan's work is. The Curse is so intense, and it only gets more so from there.

> if they want that information from the borrow checker how would they get it?

If you want to compare if two pointers point to the same place, you use https://doc.rust-lang.org/stable/std/ptr/fn.eq.html

Rust just defaults to value equality over reference equality. This is true for everything, not just ZSTs.

(I find the post's framing of "it's stored in the borrow checker" to be a bit odd, but I can't put my finger on exactly what it is. The borrow checker doesn't determine these sorts of semantics, it checks for liveliness and aliasing, so "do these pointers alias" isn't inherently not the borrow checker's job, it just strikes me as an odd way to put it. Maybe it's because you don't "ask the borrow checker for that information" really.)