Lately I'm really liking jet[1] for typesafe SQL. It requires a live DB to generate the code, but I see that as a positive as well, since you are forced to apply migrations before writing code.
Huge fan of jet. It lets you just write SQL, but in your Go. I basically can’t imagine using anything else now.
Why is that better than writing plain SQL like in sqlc? My main reason was being able to dynamically construct queries and reuse different bits. Plain SQL statements simply don’t compose at all, and I don’t recall sqlc giving any solution to help with this.
Hey, that's the same one I was taught in the Netherlands in the late 80s! It seems to have been replaced with an English-style in recent decades though, is that the case in Germany as well?
It's fascinating how similar-yet-subtly-different the cursive writing is across Europe. I wonder if you could map them into something similar to language families (or type traditions, I suppose). Would there be any "language gradient" equivalents for cursive writing across the continent? Well, before the industrial revolution I guess, I'd expect that after that you'd see more singular influences of designers backed by the state pushing for standardization of education.
According to the wiki, the Schulausgangsschrift is mandatory in 5 states and optional in 4 states (out of 16) (probably on a school/teacher level). So it still seems to be taught in some places.
After searching a bit more I discovered the situation is similar in the Netherlands too: schools can choose between the two styles (or more like three publishers each with their own styles, really).
Nitpick: binfmt.emulatedSystems is not true cross compilation. It sets up a nixos to enable emulated native compilation. After painful tinkering, i prefer this way too. When i recall correctly, for cross compilation you'd have to use nixpkgs flags.
At some point it's a matter of perspective. If the emulated system is fast, it feels the same as "true" cross compilation. In the end it's a bunch of bits and bytes which produces some other bits and bytes when we poke it. If it goes fast, it's good. If it goes slow, it's painful.
Thanks, good catch. This is a known class of edge case I am trying to improve: adjacent tokens sometimes get over-merged into a phrase reading when they should stay separate. 今 and 何 should be handled separately here, not as こんなに. I appreciate this concrete example. That helps a lot.
I hate how it's still not possible to properly style the numbers in ordered lists.
I use them for code snippets with automatic line numbers, but it's literally impossible to space the numbers (relative to the code) while keeping them aligned to the right.
¯\_(ツ)_/¯
::before has the same problem.
You can't align text inside `content:` to the right. Probably because each ::before is handled separately and can't see the sibling's content length.
I mean, the article starts by explaining the fact CSS anchors was pushed as a chrome feature. Only browsers that inherit from it by default will have this.
The article doesn't mention that it's not supported by other browsers. The two things (pushed by chrome / unsupported by others) are not consequential.
If you don't clearly state it and people start using the shiny new thing you're hindering the few alternative browsers out there.
> This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
[1] https://github.com/go-jet/jet