Remix clone Hacker News

To evaluate this as your are describing, you must reveal your estimate of the workload of what Tiger Beetle has done to roll their own docs. If it took them 5 minutes, for instance, the calculus is far different than if it took 5 years. Plus you must compare that time estimate to their other priorities to estimate the opportunity cost, something that you simply can not do accurately from the outside looking in.

And we must estimate the potential future value of what Tiger Beetle has done here. I value "no dependencies" pretty deeply and I can see how Tiger Beetle values it supremely. I don't see how you can hand waive it away so easily.

To assert that you don't believe Tiger Beetle at their word here is deeply disrespectful imo.

▲

mtlynch 9 days ago | parent [-]

>To evaluate this as your are describing, you must reveal your estimate of the workload of what Tiger Beetle has done to roll their own docs. If it took them 5 minutes, for instance, the calculus is far different than if it took 5 years. Plus you must compare that time estimate to their other priorities to estimate the opportunity cost, something that you simply can not do accurately from the outside looking in.

I don't need them to reveal their numbers to me to offer my critique, as I think few people would argue that the upfront cost of rolling your own docs site could possibly be lower than the cost of deploying an off-the-shelf solution like Hugo.

I think where reasonable people might disagree is about the total cost of ownership of Hugo vs. the home-rolled solution over five years, but I'd find it surprising if home-rolled solution wins.

>To assert that you don't believe Tiger Beetle at their word here is deeply disrespectful imo.

Where did I say that I doubt TigerBeetle's claims? I disagree with the justifications in the blog post, but it's a difference of opinion, not a question of facts.

They published this blog post, and this is HN, so I think it's well within the community standards to offer a respectful critique.

▲

bsder 9 days ago | parent [-]

> I think few people would argue that the upfront cost of rolling your own docs site could possibly be lower than the cost of deploying an off-the-shelf solution like Hugo.

I'm not convinced. At some point, you will have to debug something weird in your docs system.

If you deploy Hugo, that means understanding Go. Docusaurus--Javascript, Node, and that entire ecosystem. With this, it's Zig all the way down.

Zig users tend to be (possibly notoriously) anti-dependency.

▲

mtlynch 8 days ago | parent | next [-]

For a docs site with no special requirements, I'd be surprised if Hugo or another SSG can't do what they need out of the box. So, it's the cost of implementing your own SSG vs. the cost of figuring out how to use an existing one.

Also, just as a datapoint, I've been using Hugo on multiple sites for about five years, and I don't recall ever having to drop into Go to fix an issue. Hugo might be unique in this regard, as it ships as a single-file binary. You have to learn Go templates, but you don't have to learn anything about Go the language or standard library.

Before Go, I used Jekyll, and I don't recall ever having to learn Ruby, but I did have to work within the Ruby ecosystem because Jekyll required a Ruby environment.

Incidentally, TigerBeetle seems to have rolled their own rudimentary templating language, too.[0] I think that has potential to either limit the functionality they need or cause a lot of bugs.

[0] https://github.com/tigerbeetle/tigerbeetle/blob/0.16.29/src/...

▲

internetter 8 days ago | parent | prev [-]

> Zig users tend to be (possibly notoriously) anti-dependency.

I don't get anti-dependency, to be honest. Like say you want REGEX support in your database. You code a REGEX parser from scratch? What are the odds your parser doesn't have a vulnerability?

I think over zealous dependency usage is also bad, but it cuts both ways

	▲	popularonion 8 days ago \| parent [-]
		The post says they use pandoc for parsing, that’s a very good trade for being able to cut Node completely out of your project