N
Nick Fitzgerald
fitzgeraldnick.com · Personal blog · on HN since 2009
Nick Fitzgerald, a Rust and Mozilla engineer, writes about performance, allocators, garbage collection, WebAssembly and source maps.
What HN saysHN commenters cite it for bump allocation and benchmarks, praise its graphical benchmark charts, and link its follow-up on speed without wizardry.
43HN people shared it
16linked it in comments
46stories submitted
1.3Kstory points
3 years agolast shared
2009people per year2026
Most-shared posts
- 1Speed Without Wizardry7 people · 206 points · first shared 2018 · 69 comments on HN
- 2Always Bump Downwards7 people · 30 points · first shared 2019 · 2 comments on HN
- 3Async Stack Traces in Rust4 people · 9 points · first shared 2019 · discussion on HN
- 4Garbage Collection Without Unsafe Code3 people · 10 points · first shared 2024 · 1 comments on HN
- 5Source Maps Are an Insufficient Debugging Format for the Web3 people · 8 points · first shared 2017 · discussion on HN
- 6Demangling C++ Symbols in Rust2 people · 245 points · first shared 2017 · 44 comments on HN
- 7Destructuring Assignment in ECMAScript 62 people · 123 points · first shared 2013 · 56 comments on HN
- 8Source Maps Are an Insufficient Debugging Format for the Web2 people · 74 points · first shared 2015 · 13 comments on HN
- 9Message Passing, Duck Typing, Object Composition, and not Inheritance2 people · 40 points · first shared 2011 · 11 comments on HN
- 10Writing a Test Case Generator for a Programming Language2 people · 31 points · first shared 2020 · 6 comments on HN
- 11Synthesizing Loop-Free Programs with Rust and Z32 people · 22 points · first shared 2020 · discussion on HN
- 12Scrapmetal – Scrap Your Rust Boilerplate2 people · 7 points · first shared 2017 · discussion on HN
- 13Hiding Implementation Details with ECMAScript 6 WeakMaps2 people · 2 points · first shared 2014 · discussion on HN
- 14Rust and WebAssembly in 20191 people · 237 points · first shared 2018 · 89 comments on HN
- 15How does dynamic dispatch work in WebAssembly?1 people · 98 points · first shared 2018 · 19 comments on HN
What HN people wrote when they linked it
benmanns · 2023-09-19
Somewhat aside, I love the graphical display of the benchmark results: https://fitzgeraldnick.com/media/bumpalo-switch-to-downwards-bumping-c… --I think I'll start doing that when I run benchmarks in the future.
markdog12 · 2019-02-14
Don't forget to follow that up with the second follow-up: http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html
steveklabnik · 2015-05-15
So, in general, Rust should be good for writing VMs. If you want a JIT, though, Rust may not have any super huge advantage with it, specifically, as it would basically be all unsafe anyway.
There was a really great blog post about writing a Scheme implementation, including a GC: http://fitzgeraldnick.com/weblog/60/
ithkuil · 2023-09-27
I would argue bumping down makes it even easier to reason about alignment.
Anyways, you can find a full article about up vs down at https://fitzgeraldnick.com/2019/11/01/always-bump-downwards.html
masklinn · 2022-11-03
There was a back and forth on that subject a few years back: Mozilla rewrote their sourcemap parser from JS to naïve Rust (/WASM) for a 5.89x gain, mraleph objected to the need and went through an epic bout of algorithmic and micro-optimisations to get the pure JS to a similar level, then the algorithmic optimisations were reimported into the Rust version for 3x further gain (and much lower variance than the pure JS).
https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-…
https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-…
https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html
sanxiyn · 2022-09-04
If you enjoyed this, it is possible that you may also enjoy this Rust port: https://fitzgeraldnick.com/2018/11/15/program-synthesis-is-possible-in…
cesarb · 2022-07-15
To save some searching, the three referenced articles seem to be:
- Oxidising Source Maps with Rust and WebAssembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-…
- Maybe you don’t need Rust and WASM to speed up JS: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-…
- Speed Without Wizardry: https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html
touisteur · 2021-07-19
What's probably missing is a standard test suite for the protocol... Can't one generate one with model-based testing or another rather automatic mean. Who's the boss of the lsp project? :-)
I'm adding something from my open tabs: https://fitzgeraldnick.com/2020/08/24/writing-a-test-case-generator.ht…
vlmutolo · 2021-05-07
I wonder if it's at all related to the reasoning in this post about writing a bump allocator.
https://fitzgeraldnick.com/2019/11/01/always-bump-downwards.html
Yoric · 2018-10-29
I'm pretty sure that this was already HN-ed 6 months ago.
Nick Fitzgerald's reponse was published here: http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html
mbrubeck · 2018-04-02
And if you are willing to depend on Rust code, there's also a C++ symbol demangler written in Rust... :)
http://fitzgeraldnick.com/2017/02/22/cpp-demangle.html
acemarke · 2017-11-15
Pretty much, yeah. Today's web applications go through multiple forms of compilation and transformation. Conversion from ES6 modules to CommonJS, compilation of newer JS syntax into equivalent older syntax supported by more browsers, minification that renames symbols to cut down on the total byte size delivered, and bundling of hundreds of individual modules into a single output JS bundle (or possibly several code-split bundles). Because of that, debugging the delivered source as-is isn't feasible. Sourcemaps allow the browser's devtools to display the original source, and a developer can debug the code as it was before any compilation steps were applied.
I saw a post a couple years back that suggested that DWARF debugging symbols could be used as an inspiration for improving sourcemaps: http://fitzgeraldnick.com/2015/06/19/source-maps-are-insufficient.html .
e1g · 2014-08-31
Thank you!
TLDR: JSX transformer makes the following ES6 features compatible with old browsers (IE8+)
* arrow functions [http://tc39wiki.calculist.org/es6/arrow-functions/]
* classes [https://github.com/esnext/es6-class]
* destructuring [http://fitzgeraldnick.com/weblog/50/]
* object concise methods [http://ariya.ofilabs.com/2013/03/es6-and-method-definitions.html]
* rest parameters [http://tc39wiki.calculist.org/es6/rest-parameters/]
* template strings [http://tc39wiki.calculist.org/es6/template-strings/]
* object literal property shorthand [http://tc39wiki.calculist.org/es6/object-literal-enhancements/]
Notably absent: default parameter values and block scoping ("let")
mnemonik · 2014-06-10
I'm working on these tools now, finishing up initial platform work, should start on business logic/UI fairly soon here and get a version 0 out soon.
See http://fitzgeraldnick.com/weblog/54/ for some implementation details.
jashkenas · 2013-03-04
Right. As far as I know, they currently work in Chrome, in Node.js (with a library), in Webkit nightlies, and are getting close-ish in Firefox nightlies: http://fitzgeraldnick.com/weblog/45/
chrismorgan · 2021-10-12
Another point where it’s doing something that to me as a Rust expert is obviously inferior: it’s using Unicode-aware string stuff although anything non-ASCII will either be ignored (if non-alphabetic) or panic (if alphabetic). It’d certainly be better to treat the input throughout the program as a sequence of bytes rather than as UTF-8.
This type of thing reminds me of the three articles ending in https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html (which has links to the first two parts of the saga), where one guy rewrote stuff in Rust for performance, another demonstrated how it was possible to make the JavaScript version faster than the Rust by some algorithm changes and by various painful and fragile tricks requiring detailed knowledge of the runtime environment, and finally the first guy applied the applicable parts of that back to the Rust, after which it handily beat the JavaScript again while also being more consistent and dependable.