#krabby — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #krabby, aggregated by home.social.
-
Over the last eight months, I've been designing a query system for my very-very-WIP Rust compiler, Krabby. I'm ecstatic to announce that the design phase is (pretty much) complete! Today I'm publishing a 6500-word essay about it, covering all the fun/cursed/evil features I wanted, and how I plan to achieve them. In October, at EuroRust 2026, you'll get to see it in action. I can't express just how excited I am -- but I'm going to take a nap first.
If you have any questions or comments, don't be afraid to reach out!
-
Over the last eight months, I've been designing a query system for my very-very-WIP Rust compiler, Krabby. I'm ecstatic to announce that the design phase is (pretty much) complete! Today I'm publishing a 6500-word essay about it, covering all the fun/cursed/evil features I wanted, and how I plan to achieve them. In October, at EuroRust 2026, you'll get to see it in action. I can't express just how excited I am -- but I'm going to take a nap first.
If you have any questions or comments, don't be afraid to reach out!
-
Over the last eight months, I've been designing a query system for my very-very-WIP Rust compiler, Krabby. I'm ecstatic to announce that the design phase is (pretty much) complete! Today I'm publishing a 6500-word essay about it, covering all the fun/cursed/evil features I wanted, and how I plan to achieve them. In October, at EuroRust 2026, you'll get to see it in action. I can't express just how excited I am -- but I'm going to take a nap first.
If you have any questions or comments, don't be afraid to reach out!
-
Over the last eight months, I've been designing a query system for my very-very-WIP Rust compiler, Krabby. I'm ecstatic to announce that the design phase is (pretty much) complete! Today I'm publishing a 6500-word essay about it, covering all the fun/cursed/evil features I wanted, and how I plan to achieve them. In October, at EuroRust 2026, you'll get to see it in action. I can't express just how excited I am -- but I'm going to take a nap first.
If you have any questions or comments, don't be afraid to reach out!
-
Over the last eight months, I've been designing a query system for my very-very-WIP Rust compiler, Krabby. I'm ecstatic to announce that the design phase is (pretty much) complete! Today I'm publishing a 6500-word essay about it, covering all the fun/cursed/evil features I wanted, and how I plan to achieve them. In October, at EuroRust 2026, you'll get to see it in action. I can't express just how excited I am -- but I'm going to take a nap first.
If you have any questions or comments, don't be afraid to reach out!
-
Expect a blog post about query system design this weekend :3
-
Expect a blog post about query system design this weekend :3
-
Expect a blog post about query system design this weekend :3
-
Expect a blog post about query system design this weekend :3
-
Expect a blog post about query system design this weekend :3
-
While thinking about my query system and increment compilation, I found out that spans are really annoying. Looking into
rustc's handling of spans only made things more troublesome -- it turns out that spans infect every major component ofrustc. I looked at a bunch of use sites and have some ideas for resolving this. -
While thinking about my query system and incremental compilation, I found out that spans are really annoying. Looking into
rustc's handling of spans only made things more troublesome -- it turns out that spans infect every major component ofrustc. I looked at a bunch of use sites and have some ideas for resolving this. -
While thinking about my query system and incremental compilation, I found out that spans are really annoying. Looking into
rustc's handling of spans only made things more troublesome -- it turns out that spans infect every major component ofrustc. I looked at a bunch of use sites and have some ideas for resolving this. -
While thinking about my query system and incremental compilation, I found out that spans are really annoying. Looking into
rustc's handling of spans only made things more troublesome -- it turns out that spans infect every major component ofrustc. I looked at a bunch of use sites and have some ideas for resolving this. -
While thinking about my query system and increment compilation, I found out that spans are really annoying. Looking into
rustc's handling of spans only made things more troublesome -- it turns out that spans infect every major component ofrustc. I looked at a bunch of use sites and have some ideas for resolving this. -
An update on Krabby: There's a Zulip chat now! I wrote a little status update on the blog: https://bal-e.org/speed/krabby/hi-zulip-also-licenses/. Take a look!
-
An update on Krabby: There's a Zulip chat now! I wrote a little status update on the blog: https://bal-e.org/speed/krabby/hi-zulip-also-licenses/. Take a look!
-
An update on Krabby: There's a Zulip chat now! I wrote a little status update on the blog: https://bal-e.org/speed/krabby/hi-zulip-also-licenses/. Take a look!
-
An update on Krabby: There's a Zulip chat now! I wrote a little status update on the blog: https://bal-e.org/speed/krabby/hi-zulip-also-licenses/. Take a look!
-
The first post is up! You can read about my adventures with identifier interning in 2025: https://bal-e.org/speed/krabby/interning-in-2025/.
-
The first post is up! You can read about my adventures with identifier interning in 2025: https://bal-e.org/speed/krabby/interning-in-2025/.
-
The first post is up! You can read about my adventures with identifier interning in 2025: https://bal-e.org/speed/krabby/interning-in-2025/.
-
It's been one year and one week since I started my very-very-WIP Rust compiler, Krabby. While I used to blog about it relatively frequently, the last eight months slipped by somehow; but I was working on it the whole time! I wrote a little catch-up post (https://bal-e.org/speed/krabby/a-year/) highlighting the big adventures you might have missed out on; expect follow-up posts that dive into each one in detail.
-
It's been one year and one week since I started my very-very-WIP Rust compiler, Krabby. While I used to blog about it relatively frequently, the last eight months slipped by somehow; but I was working on it the whole time! I wrote a little catch-up post (https://bal-e.org/speed/krabby/a-year/) highlighting the big adventures you might have missed out on; expect follow-up posts that dive into each one in detail.
-
It's been one year and one week since I started my very-very-WIP Rust compiler, Krabby. While I used to blog about it relatively frequently, the last eight months slipped by somehow; but I was working on it the whole time! I wrote a little catch-up post (https://bal-e.org/speed/krabby/a-year/) highlighting the big adventures you might have missed out on; expect follow-up posts that dive into each one in detail.
-
It's been one year and one week since I started my very-very-WIP Rust compiler, Krabby. While I used to blog about it relatively frequently, the last eight months slipped by somehow; but I was working on it the whole time! I wrote a little catch-up post (https://bal-e.org/speed/krabby/a-year/) highlighting the big adventures you might have missed out on; expect follow-up posts that dive into each one in detail.
-
It's been one year and one week since I started my very-very-WIP Rust compiler, Krabby. While I used to blog about it relatively frequently, the last eight months slipped by somehow; but I was working on it the whole time! I wrote a little catch-up post (https://bal-e.org/speed/krabby/a-year/) highlighting the big adventures you might have missed out on; expect follow-up posts that dive into each one in detail.
-
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up
core::iter::Iterator") can depend on a query being processed by thread B ("parsecore/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool! -
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up
core::iter::Iterator") can depend on a query being processed by thread B ("parsecore/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool! -
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up
core::iter::Iterator") can depend on a query being processed by thread B ("parsecore/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool! -
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up
core::iter::Iterator") can depend on a query being processed by thread B ("parsecore/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool! -
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up
core::iter::Iterator") can depend on a query being processed by thread B ("parsecore/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool! -
My resolutions for this year are:
- name
- dependency
- macro, if you want to count it
- maybe a bit of type if I'm feeling cheeky
-
My resolutions for this year are:
- name
- dependency
- macro, if you want to count it
- maybe a bit of type if I'm feeling cheeky
-
My resolutions for this year are:
- name
- dependency
- macro, if you want to count it
- maybe a bit of type if I'm feeling cheeky
-
My resolutions for this year are:
- name
- dependency
- macro, if you want to count it
- maybe a bit of type if I'm feeling cheeky
-
My resolutions for this year are:
- name
- dependency
- macro, if you want to count it
- maybe a bit of type if I'm feeling cheeky
-
It's time for a little update on my very-very-WIP Rust compiler, Krabby! I haven't posted about it much recently, but I've been working at it behind the scenes. Slowly but surely, name resolution is coming together.
I've figured my approach for local nameres, and have all the right infrastructure set up. Global nameres was trickier, but I have a satisfactory plan for the underlying database. You can check it out at https://codeberg.org/bal-e/krabby/pulls/18.
A random musing about
parking_lotsomehow led me to rethinking the way tasks are defined and distributed across Krabby. Implementing it is going to take some time -- expect a blog post!My next step is dependency resolution, so that the name resolver will have more data to play with. I'm just going to read
Cargo.lockand resolve feature flags for now.
I've been having a lot of fun, and I'm excited to see where things go in 2026 (and in time for RustWeek!)
-
It's time for a little update on my very-very-WIP Rust compiler, Krabby! I haven't posted about it much recently, but I've been working at it behind the scenes. Slowly but surely, name resolution is coming together.
I've figured my approach for local nameres, and have all the right infrastructure set up. Global nameres was trickier, but I have a satisfactory plan for the underlying database. You can check it out at https://codeberg.org/bal-e/krabby/pulls/18.
A random musing about
parking_lotsomehow led me to rethinking the way tasks are defined and distributed across Krabby. Implementing it is going to take some time -- expect a blog post!My next step is dependency resolution, so that the name resolver will have more data to play with. I'm just going to read
Cargo.lockand resolve feature flags for now.
I've been having a lot of fun, and I'm excited to see where things go in 2026 (and in time for RustWeek!)
-
It's time for a little update on my very-very-WIP Rust compiler, Krabby! I haven't posted about it much recently, but I've been working at it behind the scenes. Slowly but surely, name resolution is coming together.
I've figured my approach for local nameres, and have all the right infrastructure set up. Global nameres was trickier, but I have a satisfactory plan for the underlying database. You can check it out at https://codeberg.org/bal-e/krabby/pulls/18.
A random musing about
parking_lotsomehow led me to rethinking the way tasks are defined and distributed across Krabby. Implementing it is going to take some time -- expect a blog post!My next step is dependency resolution, so that the name resolver will have more data to play with. I'm just going to read
Cargo.lockand resolve feature flags for now.
I've been having a lot of fun, and I'm excited to see where things go in 2026 (and in time for RustWeek!)
-
How can I ever explain the joy of sitting at my desk before the morning light, pulling out three whiteboards covered (on both sides!) with notes, and asking myself "what am I going to do with my compiler in the next 8 hours?".
-
How can I ever explain the joy of sitting at my desk before the morning light, pulling out three whiteboards covered (on both sides!) with notes, and asking myself "what am I going to do with my compiler in the next 8 hours?".
-
How can I ever explain the joy of sitting at my desk before the morning light, pulling out three whiteboards covered (on both sides!) with notes, and asking myself "what am I going to do with my compiler in the next 8 hours?".
-
How can I ever explain the joy of sitting at my desk before the morning light, pulling out three whiteboards covered (on both sides!) with notes, and asking myself "what am I going to do with my compiler in the next 8 hours?".
-
How can I ever explain the joy of sitting at my desk before the morning light, pulling out three whiteboards covered (on both sides!) with notes, and asking myself "what am I going to do with my compiler in the next 8 hours?".
-
My current side-side project is
phonebook, a fast multi-threaded identifier interner for Rust. I've been banging my head against the wall for the last few weeks, trying to solve concurrent reallocation; and for the last week, I've been taking a "break" by trying to build a reader-writer split API forrustls. And whilephonebookis still not feeling very appealing, the project I needed it for -- Krabby -- has plenty of other work to do. So I spent today catching up on it. I hope I can find the inspiration to tackle that concurrent reallocation issue again.I did end up building some nice stuff; a friend had contributed progress bar support a while back, and I've revamped it using
ratatui. It also includes a lot of cool detail now. Have a look!I expect the next few days to be pretty busy, so I plan to pick up
phonebooknext week; I'll focus on Krabby andrustlsuntil then. -
My current side-side project is
phonebook, a fast multi-threaded identifier interner for Rust. I've been banging my head against the wall for the last few weeks, trying to solve concurrent reallocation; and for the last week, I've been taking a "break" by trying to build a reader-writer split API forrustls. And whilephonebookis still not feeling very appealing, the project I needed it for -- Krabby -- has plenty of other work to do. So I spent today catching up on it. I hope I can find the inspiration to tackle that concurrent reallocation issue again.I did end up building some nice stuff; a friend had contributed progress bar support a while back, and I've revamped it using
ratatui. It also includes a lot of cool detail now. Have a look!I expect the next few days to be pretty busy, so I plan to pick up
phonebooknext week; I'll focus on Krabby andrustlsuntil then. -
My current side-side project is
phonebook, a fast multi-threaded identifier interner for Rust. I've been banging my head against the wall for the last few weeks, trying to solve concurrent reallocation; and for the last week, I've been taking a "break" by trying to build a reader-writer split API forrustls. And whilephonebookis still not feeling very appealing, the project I needed it for -- Krabby -- has plenty of other work to do. So I spent today catching up on it. I hope I can find the inspiration to tackle that concurrent reallocation issue again.I did end up building some nice stuff; a friend had contributed progress bar support a while back, and I've revamped it using
ratatui. It also includes a lot of cool detail now. Have a look!I expect the next few days to be pretty busy, so I plan to pick up
phonebooknext week; I'll focus on Krabby andrustlsuntil then. -
My current side-side project is
phonebook, a fast multi-threaded identifier interner for Rust. I've been banging my head against the wall for the last few weeks, trying to solve concurrent reallocation; and for the last week, I've been taking a "break" by trying to build a reader-writer split API forrustls. And whilephonebookis still not feeling very appealing, the project I needed it for -- Krabby -- has plenty of other work to do. So I spent today catching up on it. I hope I can find the inspiration to tackle that concurrent reallocation issue again.I did end up building some nice stuff; a friend had contributed progress bar support a while back, and I've revamped it using
ratatui. It also includes a lot of cool detail now. Have a look!I expect the next few days to be pretty busy, so I plan to pick up
phonebooknext week; I'll focus on Krabby andrustlsuntil then. -
Here's some simple math to help calculate performance changes when you're profiling some code. Suppose you're rewriting some function F within your program -- before the change,
perftold you it took up N% of your runtime, and after the change it's M%.- The overall speedup is
(100 - M) / (100 - N). - The speedup of the function is
(1 - 100 / M) / (1 - 100 / N).
I'm defining "speedup" here as the ratio between the old and new runtimes, i.e. how many times faster the new code is.
For example, I was optimizing my very-very-WIP Rust compiler, and I just rewrote how identifiers are interned. I replaced a
hashbrownbased solution with a custom, highly specialized hash table. According toperf, interning went from 53% of my total runtime to 12%. By the above formulae, that implies a ~1.87x speedup of total runtime, and a ~8.3x speedup of interning itself.(If you're curious, you can find the new code here: https://git.sr.ht/~bal-e/krabby/tree/main/item/src/syntax/util/ident.rs)
- The overall speedup is
-
Here's some simple math to help calculate performance changes when you're profiling some code. Suppose you're rewriting some function F within your program -- before the change,
perftold you it took up N% of your runtime, and after the change it's M%.- The overall speedup is
(100 - M) / (100 - N). - The speedup of the function is
(1 - 100 / M) / (1 - 100 / N).
I'm defining "speedup" here as the ratio between the old and new runtimes, i.e. how many times faster the new code is.
For example, I was optimizing my very-very-WIP Rust compiler, and I fixed a nasty performance bug in identifier interning. According to
perf, interning went from 53% of my total runtime to 12%. By the above formulae, that implies a ~1.87x speedup of total runtime, and a ~8.3x speedup of interning itself. - The overall speedup is
-
Here's some simple math to help calculate performance changes when you're profiling some code. Suppose you're rewriting some function F within your program -- before the change,
perftold you it took up N% of your runtime, and after the change it's M%.- The overall speedup is
(100 - M) / (100 - N). - The speedup of the function is
(1 - 100 / M) / (1 - 100 / N).
I'm defining "speedup" here as the ratio between the old and new runtimes, i.e. how many times faster the new code is.
For example, I was optimizing my very-very-WIP Rust compiler, and I fixed a nasty performance bug in identifier interning. According to
perf, interning went from 53% of my total runtime to 12%. By the above formulae, that implies a ~1.87x speedup of total runtime, and a ~8.3x speedup of interning itself. - The overall speedup is
-
Here's some simple math to help calculate performance changes when you're profiling some code. Suppose you're rewriting some function F within your program -- before the change,
perftold you it took up N% of your runtime, and after the change it's M%.- The overall speedup is
(100 - M) / (100 - N). - The speedup of the function is
(1 - 100 / M) / (1 - 100 / N).
I'm defining "speedup" here as the ratio between the old and new runtimes, i.e. how many times faster the new code is.
For example, I was optimizing my very-very-WIP Rust compiler, and I fixed a nasty performance bug in identifier interning. According to
perf, interning went from 53% of my total runtime to 12%. By the above formulae, that implies a ~1.87x speedup of total runtime, and a ~8.3x speedup of interning itself. - The overall speedup is
-
One of my issues with Rust is the "weakly typed" nature of conditional compilation. The compiler can't tell you whether your code will compile under all combination of
cfgs (including feature flags), or suggest whether you missed acfgsomewhere.I spent an hour trying to design a name resolution algorithm that is
cfg-independent (i.e. it returns something to which any combination ofcfgs can be applied to get a resolved AST), and I don't think it's practical.cfgs are too flexible; conditionally-compiled declarations can override each other in weird ways. Such an algorithm could have provided those "strong typing" features forcfgs, so I don't think there's much hope for them.At least for Krabby (my very-very-WIP Rust project), I'm going to write a standard
cfg-dependent name resolver. I have a pretty thorough design for it already. -
One of my issues with Rust is the "weakly typed" nature of conditional compilation. The compiler can't tell you whether your code will compile under all combination of
cfgs (including feature flags), or suggest whether you missed acfgsomewhere.I spent an hour trying to design a name resolution algorithm that is
cfg-independent (i.e. it returns something to which any combination ofcfgs can be applied to get a resolved AST), and I don't think it's practical.cfgs are too flexible; conditionally-compiled declarations can override each other in weird ways. Such an algorithm could have provided those "strong typing" features forcfgs, so I don't think there's much hope for them.At least for Krabby (my very-very-WIP Rust project), I'm going to write a standard
cfg-dependent name resolver. I have a pretty thorough design for it already. -
One of my issues with Rust is the "weakly typed" nature of conditional compilation. The compiler can't tell you whether your code will compile under all combination of
cfgs (including feature flags), or suggest whether you missed acfgsomewhere.I spent an hour trying to design a name resolution algorithm that is
cfg-independent (i.e. it returns something to which any combination ofcfgs can be applied to get a resolved AST), and I don't think it's practical.cfgs are too flexible; conditionally-compiled declarations can override each other in weird ways. Such an algorithm could have provided those "strong typing" features forcfgs, so I don't think there's much hope for them.At least for Krabby (my very-very-WIP Rust project), I'm going to write a standard
cfg-dependent name resolver. I have a pretty thorough design for it already.
