Perfect summary. I'll add: insane defaults that'll catch you unaware if you're not careful! Like foreign keys being opt-in; sure, it'll create 'em, but it won't enforce them by default!
Always send "pragma foreign_keys=on" first thing after opening the db.
Some of the types sloppiness can be worked around by declaring tables to be STRICT. You can also add CHECK constraints that a column value is consistent with the underlying representation of the type -- for instance, if you're storing ip addresses in a column of type BLOB, you can add a CHECK that the blob is either 4 or 16 bytes.
The fact that they didn’t make STRICT default is really a shame.
I understand maintaining backwards compatibility, but the non-strict behavior is just so insane I have a hard time imagine it doesn’t bite most developers who use SQLite at some point.
The Orbstack dashboard is also something you'll actually enjoy using. It's a native Swift app that launches instantly, not Electron. You get resolvable hostnames for all your containers (though I use traefik instead). Opening a container's filesystem in Finder is another nice trick, I use that one now and then.
I love Kubernetes, but it's still a big leap from docker-compose to k8s, and swarm filled that niche admirably. I'm still in that niche -- k8s is overkill for every one of my projects -- but k3s is pretty lightweight, easy to install, and there's a lot of great tooling for k8s I can use with it. Still wish there were something as simple as "docker-compose plus a couple bits" that was swarm mode -- I'm drowning in YAML files!
Nix is wonderful for reproducible and declarative infrastructure, but how do you manage multiple server instances with it? I have a handful of projects active at any time, and am currently running four web servers, three mysql instances, two postgres, and a partridge in a pear tree. Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?
I couldn't speak to separate physical machines, but I run several "servers" as part of my dev environment.
You'd have to ensure that their ports and data directories don't collide, but I don't think you'll have a problem having "process-compose up" start multiple separate mysql, postgres, or webserver instances.
I just dedicate a terminal pane to it so I can arrow around and see the logs and health status of my databases (plus things like Prometheus and Grafana, I like to be able to nuke the cluster and have everything flatline, rather than having telemetry itself die when k8s goes away).
There are tools such as deploy-rs, colmena, and morph that let you deploy nixOs configs using nix. I can't speak to how good they are personally, I use ansible to push my nix configs.
I may misunderstand your problem, but I just have a configuration repository for various "hosts". There are a couple of settings I share between them, and then just specify the differences.
"Deploying" one is as simple as `nixos-rebuild switch --flake .#hostName`
These are all dev environments running at the same time. I wasn't sure if Nix had some kind of port mapping or proxy config for this sort of thing. I'm still partial to having containers as self-contained build artifacts, I just like to have options as dev environments go, and "Docker from Nix" looks like the best option so far. But it's a vast ecosystem, and there's plenty I might be missing.
You just plug Nix into a service manager that you have Nix bring along for you. Many years ago, I did this for a proof-of-concept at work with supervisord[1] and flake.nix. Devenv[2] builds in[3] support for process-compose[4], which GP mentioned. A few years ago, one long-time Nixer even created[5] a framework, nix-processmgmt[6] that abstracts over various service managers including supervisord and s6[7], which can both be used in a self-contained way regardless of the init system on the host.
There are a ton of other open-source process supervisors you can use to manage long-lived processes in a portable way, too, notably Foreman[8] and various clones written in languages other than JS, and GNU Shepherd[9]. In the course of writing this post, I discovered one called dinit[10] which looks sort of similar to s6 and the GNU Shepherd in that it supports both pure usermode operation as well as functioning as an OS's init system. Anyway, all of 'em are in Nixpkgs, so you can pick them up and use them without any packaging work, too.
Service orchestration and containers are basically orthogonal concerns. Before Docker was born, there were already plenty of portable tools for standalone "process supervision", "service management", whatever you wanna call it. So it is after Docker, as well.
If I needed this for one of my dev environments I would take a look at process-compose to decide if it's acceptable to me. If it isn't, then after surveying the contemporary landscape of usermode service managers, I'd then write a devenv module that generates configs for it, and use that.
> Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?
I'd do this in a "Nix-only" way if possible, but if it's convenient for you to run a service via Docker (or Podman or any other container runtime), you can still do that.
If you can safely assume that all of your devs have it available, you can ship the client (`docker` or `podman` CLI or whatever) as part of your Nix environment, then have your process manager launch it via that command line interface. I'd avoid running Nix from within Docker for the purposes of development environments.
Wonder what this means for vimeo/psalm, the static analyzer for PHP, which has recently seen some new life breathed into it after long neglect. Psalm has credible alternatives in PHPStan and now Mago, but it would still be a loss to see it go unmaintained again.
"Markdown" doesn't have a specification, only a syntax description which is ambiguous in many places, and a reference implementation written in perl 22 years ago and totally neglected since.
CommonMark is a comprehensive specification which also has a reference implementation and a test suite.
lol this is a great wording for something I've not been able to express before
I sometimes wonder... is it Markdown's specification chaos the reason for its success? Maybe it was just barely enough spec to be usable but also small enough to allow anyone to make an implementation that seemed right. No qualifications to fail. Thus, it proliferated.
The xkcd[1] problem is a darn shame, though. At least CommonMark exists for people who want to point to a "Standard"
Markdown succeeded because both the source code and the rendered HTML are readable. Other markups like restructured text don't look good in source form.
But ya, in order to look good in source form, but still handle arbitrary content, they had to add all these little exceptions and corner cases.
Markdown is definitely a case of “worse is better” and it helped that it was half-canonicalizing ASCII formatting workarounds that had been in common use for decades.
1. People have a hard time remembering the order and which characters to use. The most common error I see is (text)[href]. Spaces in between the [text] and (href) is also common.
2. ( and ) are URL code points: they can exist in URLs without being percent-encoded. This means that you can’t just paste or emit regularly serialised URLs, you also need to change any ( to %28 and ) to %29.
To fix it, you start out by using <> to delimit the URL instead of (). This fixes the serialised URL problem (< and > aren’t URL code points), and it was the traditional delimition of URLs too, where delimition was required. You could say that () was common too, but I’d argue that was just normal linguistic parenthesis rather than URL delimition. Markdown even uses <> as URL delimition already, but only for links with no custom text (called “automatic links” in Gruber’s definition, “autolinks” in CommonMark): “https://example.com” is just text, “<https://example.com>” makes it a link.
As for the way of adding a title attribute to a link, that shows that the parentheses aren’t even actually delimiting the URL. And then you get into the mess that’s […] and […][…], in addition to […](…). It’s an ill-considered mess.
1. Seems unavoidable because there is no natural order for these two elements. It happens that html puts the link first but any time I’m writing I would put the link second.
2. I guess that’s fair. I think parentheses in urls are a bigger issue than parentheses in markdown though. Parentheses in urls often end up percent encoded whether they need to be or not.
> You could say that () was common too, but I’d argue that was just normal linguistic parenthesis rather than URL delimition.
Right. I would say that markdown is inspired more by linguistic styles than markup styles.
You certainly could use <>, but I actually don’t think that matches the way people usually write urls in non-markup formatting. I find it interesting that Gruber chose to use that for autolinks, though.
I do appreciate you clarifying. I see what you mean, at least with respect to all the issues around #2. The more I use markdown, though, the more I come up appreciate this format, specifically because it’s so readable as text. I think it’s a reasonable trade off.
> 1. Seems unavoidable because there is no natural order for these two elements.
There is a solution: restructure it so the href part is inside the link, rather than adjacent to, which is the real problem. reStructuredText had `text <href>`_. In that form, the trailing underscore is a wart, but there’s more justification to it than it may initially seem (where Markdown can have [text] or [text][], reStructuredText’s equivalent is text_ or `text`_). For my own lightweight markup language, I’ve been using [text <href>] for a couple of years (and had {text <href>} before that).
> Parentheses in urls often end up percent encoded whether they need to be or not.
That’s what you can expect from something implementing RFC 3986; but these days, almost everything uses WHATWG’s URL Standard <https://url.spec.whatwg.org/>, under whose rules parentheses are not percent-encoded.
> I actually don’t think that matches the way people usually write urls in non-markup formatting
I don’t really understand how reStructuredText’s approach fixes this. The fundamental thing is that you need to remember the order and the syntax. reStructuredText matches the order of Markdown (and so does not match html) but not the syntax. It also seems like a fine format.
> under whose rules parentheses are not percent-encoded.
I don’t know. I feel like half the time I end up with parens encoded. I’ll have to keep an eye on it. Maybe that behavior isn’t common anymore.
> [urls identified with <link> in plain text] used to be very common.
I don’t recall this being common but it’s possible I’m just not remembering.
Anything that doesn't force you to remember arbitrary ordering - square brackets first? Or parentheses? It's the textual equivalent of plugging in usb upside down.
An alternative would be to simply use square brackets for both clauses of the link.
The problem with this is that if you want to render this “pretty”, there’s no way to know whether the link should be “my website” or “website” or even the whole sentence. So you add brackets to clarify.
My issue is remembering that the square brackets come first, not the parentheses. I do like asciidoc's method: https://example.com for bare link, or https://example.com[pretty text] if alternate text is desired
Edit: It took me a re-read to fully understand your comment, I can see how square brackets might be an incremental addition. This may also help remember the syntax, thanks!
Excerpt from my notes when I was deciding on a link syntax for my own lightweight markup language:
AsciiDoc doesn’t actually have a real link syntax—what it has is more or less an natural consequence of other syntax choices, but isn’t actually URL-aware, and will mangle some less common URLs. Still, what you get is mostly this kind of thing:
But woe betide you if you go beyond what it supports, its techniques when you need escaping are grotesque, monstrous horrors. Seriously, when you fall off the happy path, AsciiDoc is awful.
Someone (maybe on this site) suggested to think of the bottom bars of the square brackets around the linked text to kind of frame the underline. Somehow worked really well for me, haven’t forgotten the syntax since.
This is great! Not an emacs user (as yet) but this and org-mode's /italic/ _underline_ *bold* +strike+ feel that much closer to the oft-touted "source looks kinda like formatting” ideal of markdown. Not sure why we ended up with the mediocre version as a defacto standard.
The only keyboard shortcut for org-mode and markdown-mode I consistently remember is C-c C-l for inserting links. Much easier to remember that than to remember the syntax, and the fact that both modes use the same easy-to-remember shortcut is a major win.
Sadly, most other keybindings differ between org-mode, markdown-node, and auctex. I would have loved more consistency, and often end up typing the syntax instead of tripping up keybindings.
My feeling overall is that I can't get into flow writing Markdown, there are just enough things wrong that I never feel completely comfortable while doing it.
It seems that in the HTML 5 age there is some subset of HTML which should be completely satisfying for anyone. Maybe it is custom components that work like JSX (e.g. <footnote>) or something like tailwind. Editing HTML with one eye on a live view is more pleasant for me than anything else. Every kind of rich editor that looks like Microsoft Word (esp. Word!) comes across as a dull tool where selections, navigation, and applying styles almost work. There's got to be some kind of conceptual problem at the root of it all that makes fixing it like pushing around a bubble under the rug. I want to believe in Dreamweaver but 2-second latency to process keystrokes on AMD's best CPU from 2 years ago and the incredulous attitude Adobe support has about the problem makes it a non-started [1]
[1] if I ran an OS failing to update the UI in 0.2 sec gives an immediate kill -9 and telemetry of the event will get you dropped out of the app store not much later. I'm not saying rendering has to be settled in 0.2 sec but there has to be some response that feels... responsive.
To my memory, people had been using [link](url) and similar styling for a long time on old web forums and even BBSes.
Be glad they didn’t adopt Everything2’s “pipe link” syntax: [link|url]. Or maybe it was [url|link]? It’s been well over two decades, I don’t remember anymore.
I have never heard of [text](url) being used before Markdown. “text (url)” or “text <url>”, leaving the reader to infer which words the URL applied to, sure; but among formats that provided a span for the link text, I think Markdown may have been the first to use a spelling of two adjacent delimited parts. [urltext], [text|url], [url="url"]text[/url], et cetera, seen them all.
HTML and CSS were also chaotic at one point and it sucked ass.
Loosy goosy is fine for a hobby project but if you do anything with vanilla Markdown beyond simple links, headings and text, you quickly find yourself in a frustrating zone of incompatible hacks and syntax extensions.
I maintain knowledge bases in Obsidian compatible repositories and one thing that's been great is having a hand rolled validation schema that validates against the AST output produced by remark. I call it a "markdown body grammar". So I can at least prevent people from doing edge casey things at build time when they produce documents
I generally like John Gruber and have been a DF reader for years, but I really never understood his perspective on this; I have trouble seeing it as much more than a "worse is better" kind of take.
Yeah I ultimately can't hate markdown, but it really was just specified more or less as "whatever markdown.pl does", and markdown.pl was not exactly the most rigorously engineered thing. Even bbcode of all things has more predictable structure to it. The commonmark/pandoc guy now has Djot, which is supposed to be a bit more sane, but I get the feeling it's probably too late :-/
reply