brson

I'll take this opportunity to report on my Framework Laptop 13 experience. I've had it for over a year.

The case is warped in multiple places. One USB C module doesn't accept a power charge reliably. It can overheat and shutdown. If the case flexes a little the trackpad stops responding - it needs to be on a flat surface. Power brick died.

On the plus side, my partner had one and when she threw it away she gave me her parts and I was able to swap some out. That was cool.

I felt similar about the book. The premise was thrilling, but as it went on it seemed to succumb to typical genre tropes, ending didn't deliver.

Quite a lot of type system modeling has gone into Dada so far, though I don't know the details. Some of that work is here: https://github.com/dada-lang/dada-model

Rust borrow checker author's new language designs.

Follow up posts:

https://smallcultfollowing.com/babysteps/blog/2026/02/09/hel...

https://smallcultfollowing.com/babysteps/blog/2026/02/10/dad...

https://smallcultfollowing.com/babysteps/blog/2026/02/14/sha...

RIP

Miri is so good. Thank you Ralf for dedicating yourself to this project for so long.

When I have Rust projects with subsystems that must be unsafe, I will design them around Miri testability. This mostly means writing small unit-testable units and isolating I/O as much as possible. I almost always find I have made mistakes that Miri catches.

I also clicked through a few times trying to get a clear description of what this is with no success.

This is a surprisingly wide-ranging video about robots and AI in context of Disney's theme parks.

I wanted to love this so much but my eyeballs were screaming trying to read the text over the crawling dither pattern.

Congrats to the servo team. It's been a long road and it's amazing they kept it alive.

I've been using slint for a desktop project recently and having a lot of fun with it - it's pretty simple and the design has an interesting and fairly clean separation between the UI language and the backing application code (in Rust in my case). Recaptured a bit of my lost love for desktop apps.

The TigerBeetle database docs have a page on financial accounting that is just a really good overview of double-entry accounting.

Rust was specifically designed to be refactorable and in my experience it is. It was part of the dogfooding process of building Rust in Rust - lots of changes to the language, lots of changes to the compiler, lots of churn. Rust's strong type system means you can refactor and be confident that programs continue to work.

To the students and mentors: congrats. GSoC is a great program and a great way to get involved in the industry. I hope you had an amazing experience.

Not to take away from them, but the first sentence of this official Rust post kinda stunned me: "the Rust Project participated in Google Summer of Code (GSoC) for the first time this year". There may be an interpretation of this sentence that is true, but multiple students have worked on Rust GSoC projects under Mozilla (which at the time ran the Rust Project), and quite a few worked on Rust GSoC projects under other organizations.

At the least, Michael Woerister worked on debuginfo in 2013, and Igor Matuszewski on the RLS in 2017. [1] [2]

Please Rust Project do better at remembering your history.

[1] https://blog.gerv.net/2013/06/gsoc-2013-project-list/

[2] https://summerofcode.withgoogle.com/archive/2017/projects/52...

I use this daily instead of python3 as a simple calculator via the repl, and for that purpose it is indistinguishable from python.

Having so many students involved in Rust was huge. Definitely the most rewarding thing about working on Rust was seeing students get involved, grow, then turn that experience into a career, while seeding the industry with Rust talent.

Rust was explicitly designed from the beginning for creating maintainable large-scale software.

Here's the original elevator pitch from 2010:

https://github.com/rust-lang/rust/blob/d6b7c96c3eb29b9244ece...

Note the text about "programming in the large".

There are. Here is a copy of my notes on the subject:

https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48...

Sorry it's not more organized and detailed.

Reddit also uses commonmark, plus some GitHub flavored markdown extensions, via the comrak library, plus some custom extensions. So Reddit markdown should mostly look like GitHub.

That version of Rust also did async I/O in the runtime. Async I/O has always been part of Rust. The model changed because there was too much overhead doing it the more ergonomic way and it got booted out of the runtime.

I don't think so. I don't see anything to click that would let me do that, but I'm happy to do so if someone tells me how.

Just remembering this deck and thought it might be interesting to this audience. This is the very first public documentation about Rust (Servo is not actually defined in this deck...), Graydon's slides from the Mozilla Summit 2010, dated 2010/07/07.

As far as I can tell, beyond this talk, there wasn't a formal "announcement" about Rust's initial open-sourcing (if somebody knows otherwise please link). It was mentioned the next day on LtU: http://lambda-the-ultimate.org/node/4009

I'm sorry you had a bad experience with PingCAP.

I can't speak for PingCAP in general, but I know that many of PingCAP's Rust projects are part of the TiKV org [1], which is explicitly trying to become more community-oriented as part of their move into the CNCF (I work for PingCAP on TiKV). This message won't reach far, but if somebody finds themselves having difficulties contributing to TiKV or communicating with TiKV maintainers, and they speak up on the TiKV slack, somebody will definitely take notice and try to help.

Not knowing the specifics of your experience, it might help to consider that most of PingCAP are Chinese, and some communicate in English better than others. In public forums like the issue tracker, they write in English to include the global software development community, but for some it is quite challenging.

I'm hopeful that the PingCAP process will improve and their projects will become easier to contribute to.

[1] https://github.com/tikv/

This project and its predecessor are so cool. I've been glad to see their continued progress.

It's probably not wise to post this, since I never talk about it publicly, he might not like it, and this thread should be about GrapheneOS, not Rust or myself. But with the mention of his Rust involvement and the history of CopperheadOS, I feel compelled at the moment to add some context and give him props.

He is an exceptionally skilled developer.

Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code.

And from what I recall he was in high school at the time. Amazing.

I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone.

It is totally fair to say that Rust would not be what it is today, both technically and socially, without him.

I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS.

Good luck, Daniel.

(edited to remove some Rust cheerleading)

This resource is intended to teach about the crate ecosystem.

A similar resource that focuses more on the language and standard library is Rust by Example:

https://doc.rust-lang.org/stable/rust-by-example/

I'm not really up to speed on what the Rust team is thinking, but basically no. These are not the kinds of things the Rust team would do to improve ergonomics. Correctness is forefront in Rust. The only thing I can think of like this op that has seriously been considered is automatic cloning for trivial types like `Rc`.

The Rust team thinks really hard about correctness before making any decisions and isn't going to add any ridiculous footguns to the language unless there's some organizational catastrophe that puts monkeys in charge of decision making.

I think no. The stuff the op is describing is mostly not on the ergonomics agenda (I was thinking "strawman" while reading this), except for possibly limited automotic cloning for trivial types like `Rc`. It doesn't seem to describe the team's actual thinking about ergonomics. The Rust team is very aware of the importance of writing foolproof correct code in Rust (that's what it is designed for), and unless some major shift happens, I doubt they would make any major correctness sacrifices for the sake of ergonomics.

The Travis smoke tests against PRs are only done in a single configuration, so are relatively cheap.

I think it would double expenses because our CI runs at capacity. To do parallel builds we would have to contract for double the compute resources. (With a different purchase structure for our CPU time you may be right about that, but not sure).

Yes, my impression is that many production-grade compiler dev teams have technique like this, though often they do not talk much about it, often they are proprietary and/or covered by NDAs, and often they are, as you say, 'selected' code bases. I'm very curious for other compiler teams to say more about what they do here.

Oh, neat. I've never heard it proposed quite that way before, where both branches being tested are compatible. That's real smart.

So far we haven't been able to stomach doing parallel integration builds because of the doubling of expenses.

As you see, our current solution is rollups, where a human batches low-risk PRs into one big PR. It works just ok, and is super high-maintenance.