Dan Luu

Having gone through Rustlings these past few days (via https://users.rust-lang.org/t/best-way-to-learn-rust-programming/47522/3), I feel like the speed of the Rust compiler has gotten a lot faster since I looked at it a few years ago.

And the compiler messages (once you get the hang of it; and the investment in learning the syntax is so trivially worth it in the long run) are so much richer and more helpful than other languages. So it really does "feel" like a REPL or most of the way there as a REPL (and I have one of the few wikis at our work advocating for Common Lisp that I wrote a year ago, and still actively follow Clojure groups, etc.).

It's just Rust starts and runs so fast (and Cargo makes it easy and clear like Go); so that being able to re-run periodically really fast is like a REPL. Yeah there's no retained state or ability to keep a REPL running for days, etc. (though Tmux.. and nix as a repl.... more on that later), but it's reached a point where compilation is an OOM faster than before, so the loop of: read, eval, print now can include the compiler.

And you get this amazing boost where if you're operating e.g. on large data (if you're a senior engineer, like Dan Luu blogs https://danluu.com/, you're often scanning codebases or log files or other metadata to answer questions); so being able to tweak and re-run even without caching at OOM faster speeds than other languages is wonderful.

I can create complex refactoring scripts in Rust on GBs of data and…

> 2 of them have normal sized text and 1 has [...]

No, one of them (Wikiwand) has "normal sized text", and the other two have objectively shrunken text. This is not a matter of opinion; this is fact. Both HN and Wikipedia, like I mentioned before, are overriding the text size in their stylesheets to force the main body text to display at a size smaller than the UA preferred size. Wikiwand is using the correct font scaling. If you have a problem with the size of the text on the Wikiwand page, it's because your UA is configured to show text at a size that you have a problem with. It's up to you to deal with that.

For an example of what properly-sized text looks like, have a look at http://cr.yp.to or http://danluu.com. These sites are not sending any "designer" styles to your browser (aside from the 8 lines of CSS for the latter, which don't affect the text size).

Besides that, your criticism of Wikiwand's design is dominated by details about its layout and not its text size. But I didn't say Wikiwand was the best layout in the world; it's not, and I don't even use it. But it's still not worse than Wikipedia's overly-designed Vector skin.

Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and the latest Chrome.

A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they just work.

My website: https://www.instantfloppy.net/ (though admittedly I don't spend as much time on it as I should)

[0]: https://danluu.com/

[1]: http://michaelnormanwilliams.com/

There are two aspects to compute performance: latency and throughput.

There has been a ton of work to improve throughput, but that's often come at the cost of latency, because a great technique to improve throughput is batching, to avoid the per-task overhead cost.

We've also added many layers of abstraction.

A seminal example is Dan Luu's "computer latency" table (2017) https://danluu.com/input-lag/, which measures the time between a keypress and visible changes on the screen, and wherein an Apple IIe has latency 5x lower than a Lenovo X1 Carbon on Windows.

From some perspective, you could say that the Lenovo on Windows example is an impressive feat of engineering, considering all the subsystems involved (USB, interrupt dispatcher, input layer, windowing system, double-buffering...)

This throughput-over-latency tradeoff can be seen across the entire computer landscape design.

I used to be a huge VHDL proponent, talk about the delta cycle stuff, give VHDL classes at work to new college grads and such. And then I moved to the West Coast and was forced to start using Verilog.

And in the 21 years since, I’ve never once ran into an actual simulation determinism issues.

It’s not bad to have a strict simulation model, but if some very basic coding style rules are followed (which everybody does), it’s just not a problem.

I don’t agree at all with the statement that Verilog fails when things become too complex. The world’s most complex chips are built with it. If there were ever a slight chance that chips couldn’t be designed reliably with it, that could never be the case.

Anyway, not really relevant, but this all reminds me of the famous Verilog vs VHDL contest of 1997:
https://danluu.com/verilog-vs-vhdl/

Best quote over on distributed systems as applied to humans (from Dan Luu):

"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"

- from https://danluu.com/sounds-easy/