I installed Jellyfin on my home server a few months ago but it’s already broken by upgrading to 10.11, and unusable until I restore 10.10 from backup or start over: https://github.com/jellyfin/jellyfin/issues/15027. There seem to be lots of other database migration bugs for this release and other ones.
> For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all.
It's not just about performance, it's about reusability. There is a huge amount of code written in languages like Java, JS, Go, and Python that cannot be reused in other contexts because they depend on heavy runtimes. A library written in Zig or Rust can be used almost anywhere, including on the web by compiling to wasm.
Another thing to watch out for with SVGs is how they appear in RSS readers or browser reader views. If you're using external SVG files then it should be fine. If you've optimized them by embedding into the HTML, then you need to be careful. If they rely on CSS rules in the page's CSS then it's not going to work well. For my website I try to make the SVGs self-sufficient by setting the viewBox, width, and height attributes, using a web safe font, and only relying on internal styles. You can still get some measure of light/dark mode support by setting fill or stroke to currentColor.
I used that Hario grinder for years but eventually the clear base part broke. I continued using it by grinding directly into the AeroPress but it was pretty annoying. I finally upgraded to a KINGrinder K6 and it’s amazing how much better it is. It grinds way, way faster.
Assuming you’re seeing the same issue as me: I find the parenthesis spacing is messed up whenever there are unnecessary \left and \right, as there are in some of the samples, which leads to an extra <mrow> in the MathML. If you only use those when they really need to stretch, then it looks much better.
If you want to test out some examples from your website to see how they'd look in KaTeX vs. browser MathML rendering, I made a tool for that here: https://mk12.github.io/web-math-demo/
I agree with you. My point is that the additional feature (references) creates a new potential for UB that doesn’t exist in C, and that justifies the “doesn't really ever occupy my mind as a problem” statement being criticized upthread. You can’t compare C to Rust-without-references because no one writes Rust that way. It’s not like C++-without-exceptions which is a legitimate subset that people use.
There is an important difference for this case though. It C it’s fine to have pointers into uninitialized memory as you as you don’t read them until after initializing. You can write through those pointers the same way you always do. In Rust it’s UB as soon as you “produce” an invalid value, which includes references to uninitialized memory. Everything uses references in Rust but when dealing with uninitialized memory you have to scrupulously avoid them, and instead write through raw pointers. This means you can’t reuse any code that writes through &mut. Also, the rules change over time. At one point I had unsafe code that had a Vec of uninitialized elements, which was ok because I never produced a reference to any element until after I had written them (through raw pointers). But they later changed the Vec docs to say that’s UB, I guess because they want to reserve the right to use references even if you never call a method that returns a reference.
I do this but additionally with an always-on Raspberry Pi, so syncing works perfectly even if the laptop and phone aren’t able to sync directly to each other. The SyncTrain iOS app arrived just in time for me: https://t-shaped.nl/posts/synctrain-a-rethought-ios-client-f...
You can login with a passkey now: https://tailscale.com/kb/1341/tailnet-passkey-admin. It looks like you still have to use Google/etc. for your main account initially. But still, this would prevent getting locked out.
Kudos for finishing it. I’ve gone on a similar quest with https://mk12.github.io/sicp, but I’m still on chapter 3. I keep getting distracted by new ways of improving the website rather than making progress in the book.
One reason it’s harder to follow is you can’t have references to uninitialized memory. In Zig pointers to uninitialized memory are fine as long as you don’t dereference them. That’s also true of Rust’s raw pointers, but most Rust code uses references, so it can’t be reused in unsafe contexts.
As a concrete example, I previously used Vec in unsafe code that dealt with uninitialized memory. This should be fine because Vec is basically a raw pointer and two integers. But later they changed the docs to say that this was undefined behavior (essentially, Vec reserves the right to “produce” a reference whenever it wants, even if you avoid calling methods that would do that). So my code that previously followed the rules now appeared to violate them.
This is another big difference between Rust and Zig. Rust lets you have it both ways with configuration. Zig places much more value on being able to read and understand any Zig code in the wild, based only on “it compiles”. Rust’s “it compiles” gives you lots of information about safety (modulo unsafe blocks), but very little about certain other things until you’ve examined the 4-5 places which might be tweaking configuration (#[attributes], various toml files, environment variables, command line flags).
If you allow shadowing, then you rule out the possibility of the value being used later. This prevents accidental use (later on, in a location you didn't intend to use it) and helps readability by reducing the number of variables you must keep track of at once.
If you ban shadowing, then you rule out the possibility of the same name referring to different things in the same scope. This prevents accidental use (of the wrong value, because you were confused about which one the name referred to) and helps readability by making it easier to immediately tell what names refer to.
It’s harder to write correct unsafe Rust than correct Zig because (1) Rust uses references all over the place, but when writing unsafe code you must scrupulously avoid “producing” an invalid reference (even if you never deference it), and (2) there’s lots of syntax noise which obscures what the code is doing (though &raw is a step in the right direction).
I host my site on NearlyFreeSpeech for about 40 cents a month and there’s no bandwidth limit. The FAQ has always said: “Currently we are not tracking (and hence not billing for) extra bandwidth usage. This could change in the future, but currently we have no such plans.” Even though I could host with Cloudflare for $0, I think the tiny savings are not worth imposing the captcha on people.
The problem is not that + calls a function. The problem is that + could call one of many different functions, i.e. it is overloaded. Zig does not allow overloading plus() based on the argument types. When you see plus(), you know there is exactly one function named “plus” in scope and it calls that.
FWIW the goal for comptime Zig execution is to be at least as fast as Python. I can’t find it now but I remember Andrew saying this in one of his talks at some point.
I just started a new job where I’m collaborating with the maintainers of mercurial, and was asking them about these alternative VCSs last night. It was interesting to learn that all these people are in contact with each other and there’s a lot of cross pollination of ideas. And for some newer ideas e.g. in jj and pijul, where just reading the website would have me 100% sold, they had more nuanced takes on the pros and cons. So I feel less confident in giving advice than I would have a few days ago. But if you need seamless git compatibility, I’ve personally found git-branchless to be the best solution for the requirements you listed as a thin layer over git. I also tried jj a while back and I liked it but I found being further removed from git made it harder to drop down into regular git when I needed to. In particular I had issues with jj log showing lots of irrelevant commits but that was probably because of our particular Gerrit setup and might have been fixed by now.
I find it weird how so much generation discussion seems to skip gen x. I see references to boomer, millennial, and zoomer/gen z way way more often than gen x.
I like this approach. It makes me wonder though, what about <i>, <em>, <dfn>, <cite>, etc.? They all look the same by default and as far as I know there is no UX advantage to using them properly. Do screen readers differentiate them? It doesn’t seem necessary for accessibility when sighted users can’t tell the difference either.
I know it’s not the point of your example, but you should not check if a file exists right before opening it. It could get deleted in between exists(file) and open(file), so you still have to handle the case where opening fails with FileNotFound.