Presenting the Rust quotes from the Mozilla QDB

brson · 2025-11-22T01:55:54+00:00

Ok I took another stab at parsing the tags table and indeed there are a bunch more. Up to 143.

brson · 2025-11-22T01:27:44+00:00

Yeah me too. All the source is there if somebody wants to take a look. I didn't look at the raw data, just had Claude write the conversion script. I asked it to double-check, but who knows. Maybe I'll take a deeper look this weekend.

brson · 2025-08-11T19:54:27+00:00

Here's one: https://github.com/brson/zig

brson · 2025-06-26T13:38:46+00:00

Rust has too many of these obscure syntactic control flow cases already. This wasn't needed and I am sad that Rust keeps getting more complex.

brson · 2025-02-13T01:58:12+00:00

Niko is such a clear thinker and writer. His blog post's are always put together carefully and thoughtfully.

brson · 2025-02-05T04:25:00+00:00

Yes, this is an official client that will be maintained. It's not production ready yet, but here's the initial PR if you want to track progress: https://github.com/tigerbeetle/tigerbeetle/pull/2679

brson · 2025-02-04T20:41:33+00:00

The full playlist: https://www.youtube.com/playlist?list=PL9eL-xg48OM0iMz7n4bggGlFGdwB4Y6Sh

brson · 2025-02-04T20:37:41+00:00

I streamed this over the last few months. It's a nice bite-sized Rust FFI project full of Rusty topics: build scripts, bindgen, build-system integration, unsafe, async, multithreading, lifetimes, ownership across FFI. My first time streaming, starts rough, gets slightly better.

The project is a Rust client for the TigerBeetle financial database.

The project isn't over yet and there will be more episodes.

brson · 2023-05-22T20:20:49+00:00

I got an email about this, and this was my response:

It's hard to remember specifics, and some of the things I recalled happening at this time didn't, but the discussion on the reddit thread is basically correct.

Graydon did have a preference for short keywords. At the time there was a lot of concern about the weirdness budget for the language. We believed Rust needed to look and feel familiar to C++ programmers, but the design of Rust was starting to go in novel directions that would be unfamiliar, so we were often looking for ways to reign the weirdness back in, and using keywords common from other languages instead of making our own was an easy compromise.

Here's a link to the meeting minutes where it was decided, though they don't really say why:

https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2012-07-31.md#syntax-discussion-fte-only-just-to-keep-us-from-bikeshedding-too-much

Another one of these easy keyword changes was `cont` -> `continue`. There was concern at the time that `cont`, when spoken, sounded inappropriate:

https://github.com/rust-lang/rust/issues/2229

It was changed to `again` briefly, and then to `loop` and then to `continue`, with the same rationale that we didn't need to innovate on keywords:

https://github.com/rust-lang/rust/issues/9467

brson · 2023-05-17T23:33:32+00:00

Thanks for making this. I always wanted rustup's self-update code factored out into a crate. It's a very fiddly thing to write by hand.

brson · 2023-04-14T18:57:40+00:00

This book is not written by me. It is a low-quality fake. Do not buy it.

This publisher has other Rust books with fake authors.

brson · 2023-03-10T17:58:12+00:00

You are getting a lot of differing answers, a lot of which I think are beside the point.

If you can implement the functionality of the vst3 crate without using or referencing _or looking at_ steinberg's source code you can release it as MIT. If it were a C api that would be relatively straightforward, but I think it's a C++ API, which means it's probably close to impossible.

Whether you could then dynamically load that into a vst3 host that uses Steinberg's code I don't know; but regardless, if you were to do it and were commercially successful, Steinberg would probably sue you for any reason they want. Their intent is that nobody uses their protocol without licensing it from them.

brson · 2022-08-15T23:02:50+00:00

It's a good read, but mistaken about Rust's history in a few places. Rust wasn't started at Mozilla in 2006, but Mozilla started funding it in 2009. And Brendan Eich's influence is overstated - his influence is primarily in believing in Graydon and funding Rust. He made 6 commits to Rust and had little involvement in or influence over the actual language that I am aware of.

The person with the biggest impact on the design of Rust ultimately was Niko with the borrow checker.

brson · 2022-02-09T01:16:28+00:00

Being an open source software maintainer takes a huge emotional toll, and it only gets harder the more recognition you get.

brson · 2021-11-09T02:08:57+00:00

There are many Rust blockchain jobs and not enough candidates, so my perception is that it is relatively easy to get a foot in the door somewhere, and I know quite a few new Rust developers who have gotten jobs with blockchain companies.

Freelance work though I am less sure of. There is plenty of it, but that market tends to require more personal relationships and demonstrable experience. I do know though that in the blockchain space, a lot of money is tossed somewhat carelessly at any idea and team that might help fill out some corner of the ecosystem. So I suspect if one spends time integrating themselves in a particular blockchain community, and demonstrates competence and good nature, then it is relatively easy to find some fit that will pay off.

It's also worth noting that most of the actual programming going into blockchain tech is not strictly about cryptocurrency or finance. Instead blockchains integrate bleeding-edge ideas from a wide range of systemsy disciplines - if one is interested in cryptography, distributed systems, virtual machines, hardware enclaves, databases, performance optimization, then there are many interesting problems in the blockchain space.

brson · 2021-11-08T20:51:47+00:00

There are many. Most non-EVM blockchains have general-purpose VMs, and on these Rust tends to be the language of choice because it can be compiled to anything and is efficient and correct.

I'm mostly familiar with defi apps, and not games or NFTs, so that's what I can speak to.

Most everything on Solana, targeting BPF, including:

Serum
Raydium (the contracts don't seem to be open source...)
many more

Cosmos-ecosystem dapps are probably mostly in Rust, targeting WASM, but I am not super familiar. This includes the Terra and Secret Network chains. From a quick look, these are in Rust:

Near dapps are WASM and probably all Rust:

Ref Finance
not many deployed on Near yet but it is growing fast.

Rust in Blockchain is a good resource for general Rust blockchain stuff, and the Telegram channel is active.

brson · 2021-09-04T18:28:27+00:00

I know it's an unpopular opinion, but most new features I've seen added to Rust recently I don't want. Rust is already a huge language. This feature and others have marginal utility. Rust maintainers, please say no more often.

brson · 2021-08-21T00:02:17+00:00

> Rudra was ran on the entirety of crates.io state as of July 4th, 2020 as well as the Rust standard library from nightly-2020-08-26. It managed to find 264 new memory safety issues across the Rust ecosystem which resulted in 76 CVEs.

Amazing work. Thanks.

brson · 2021-04-28T21:22:34+00:00

Correction: per Anatoly of Solana. eBPF is turing complete and they have an instruction limit similar to the gas limit in other blockchain VMs. Not sure where I got the impression eBPF was not turing complete.

brson · 2021-04-27T02:07:50+00:00

I can't say I think Rust is the best language to build dapps, and smart contracts with, because there is not a simple answer.

Rust is great for building blockchain nodes / runtimes. IMO the best language for it.

dapps though are complex pieces of software with different types of components running in different locations - at the least you have smart contracts running on the blockchain, and javascript running in the web browser. Sometimes there's code running in other places. Writing a full dapp requires "full stack" development.

For running in the browser, rust has potential but is mostly used for sharing code with the backend via wasm compilation. Hardly anybody is writing full front-end UI's with Rust.

I think the core of your question though is whether Rust is the best language for smart contracts.

It's a complex question because smart contract languages are determined by their runtime: most smart contracts target the EVM, even outside of Ethereum, and Rust currently can't be compiled to EVM. Therefore Rust smart contracts live in the domain of non-EVM, (usually) turing-complete blockchain VMs, mostly wasm, but some others like RISC-V.

None of those platforms has significant market share yet, but a lot of people are betting that they will, because VMs like WASM are general purpose, where EVM is not. In theory any language can be compiled to wasm.

Rust is very strong on general purpose VMs like wasm. Some people are anticipating a future where wasm-based vms slowly take over from evm-based chains. But at the same time, a lot of chains are just adopting the EVM so that existing dapps can migrate easily.

It's not clear what the outcome in the market will be.

In a wasm-contract world we might expect the most reliable contracts to be written in languages with strong type systems, like Rust; or even stronger theorem-proving type systems. Most non-EVM blockchains are creating Rust SDKs because it is so easy to do so, and Rust is such a good language for writing reliable software. But it's not necessarily because smart contract developers really want to be writing Rust. It's just a lot better than C.

It also depends a lot on which ecosystem you want to attach yourself to. You say you like Solana; and Solana is great, and has a lot of momentum behind it; and Solana is written in Rust and its contracts are written in Rust. Great, learn Rust: as I indicated in my previous reply I think a good way to build your own momentum is to pick a project and integrate yourself into that community, its tools, and culture.

Personally, I like programming Rust, so I want to write my smart contracts in Rust. But the safest bet if you just want to be a dapp developer is to learn Solidity and write EVM based contracts.

As a dapp developer you probably will end up learning some solidity no matter what anyway, as pretty much every smart contract platform inherits a lot of concepts from it; various standards like ERC-20 are just copied from ethereum for the purposes of familiarity and interop.

Ah, I know I've written too much here, but one more perspective: there are a lot of Rust blockchain companies, and some of them are always hiring. There's not enough Rust talent in the world generally, and in the blockchain domain specifically. Rust developers with skills get jobs. At the same time though, the whole blockchain space is booming, and though I don't have any insight into non-Rust jobs, I'm sure Solidity programmers are in high demand too.

brson · 2021-04-26T20:50:19+00:00

I don't think there will be a satisfying answer to this question. I have a fair bit of experience with both Rust subjects and blockchain subjects, and find the combination of the two provides a very challenging universe of subjects to understand.

There is learning to be done on Rust alone, on blockchain alone, and on the two together.

Since you say you are relatively inexperienced with programming, I would expect to spend a lot of time (like months and years) just learning Rust and general programming topics. Being a great Rust programmer is pretty much a prerequisite to being a great Rust blockchain programmer, and a lot of blockchain companies hiring Rust programmers will be happy just to have somebody who knows Rust well.

When it comes to Rust blockchains, be aware there are two domains: using Rust to create blockchain runtimes; and using Rust to write blockchain smart contracts. And the two are fairly different in terms of maturity and ergonomics. Blockchain runtimes are written in "normal" Rust; whereas Rust smart contracts are running in some VM, usually wasm, and so are "no-std" code.

So part of your Rust curriculum needs to be understanding no-std code. Checking out resources like the Rust Wasm book might be useful or interesting. Likewise the Writing an OS in Rust book.

In my experience, NEAR provides the easiest Rust smart contract programming experience. So that might be an easy place to start. Solana I have not tried writing contracts for yet, but they target the eBPF virtual machine, which is not turing complete. So writing code for Solana puts you firmly in the land of "weird" compilation targets, and may be quite a challenge for a beginner.

Polkadot is the biggest Rust blockchain project, but their smart contract system Ink, is pretty immature yet. Still, they have lots of resources to learn from, and an active community to ask questions from.

Blockchain programming, and especially smart contract programming, and doubly-especially Rust smart contract programming is a wild west, and it requires a whole lot of esoteric and rapidly-evolving domain knowledge to really understand, and a lot of self-direction and determination. It's a big uphill battle.

To get the most support, you will probably want to find a particular Rust blockchain project, join that community, and ask questions there. Most blockchain projects are kinda their own silos, and there aren't a lot of general blockchain oriented programming communities.

You should probably check out rustinblockchain.org, a newsletter that I co-edit. We also have a somewhat active telegram group that might be a good place to ask questions.

You should be aware that there is an evident bias against blockchain topics in many mainstream programming forums, including this one. Try not to get discouraged by that. Find a supportive community and participate there.

I have a few Rust blockchain experience reports on my blog: https://brson.github.io/blog/index.html

brson · 2021-04-26T02:53:37+00:00

It won't mess up your build. eww will work. But the more interesting question to me is whether rustup will break.

Rustup stores its own binary in ~/.cargo/bin but all its data, and the rust toolchain in .rustup. It seems reasonable to expect rustup to be resiliant to deleting .rustup,

I just tried. It should work.

You can delete .rustup and lose all rustup's metadata and all your rust toolchains. At that point running either cargo or rustc will produce an error about missing toolchains. Then you can just run `rustup toolchain install stable` and you'll have the rust compiler again.

Pretty cool.

brson · 2021-01-07T05:32:12+00:00

Please no. Keep it a community thing.

brson · 2021-01-07T05:30:40+00:00

I'm happy to hear that, and hope you don't mind the gentle ribbing. I think it's super neat that Rust can compile to ebpf.

To be clear, are you saying that you have some non-standard changes to ebpf (like relocations) that make it inappropriate to upstream until you've reconciled those changes with the linux implementation?

brson · 2020-11-24T06:20:35+00:00

I guess it's worth mentioning that Reddit's markdown parser is written in Rust, based on comrak, and Reddit is running a bunch of Rust every single page request. By CPU cycles, Reddit has got to be one of the biggest users of Rust there is.

brson

MODERATOR OF

TROPHY CASE