tapirl

This is one reason why I created TapirMD, which offers better specificity.

CSS sucks because it is sometimes elegantly simple and intuitive, other times a maze of quirky, frustrating hacks.

Similar to my "Go 101" books website, about 1000 line of Go code (started from 500 lines at 9 years ago). The whole website can be built into a single Go binary.

typo: s/with/without/

> Tabs should be navigable by arrow keys [4], which also requires JavaScript.

It supports this now (with JavaScript). If not, try to refresh the page.

for "accessible", do you mean getting focused when pressing TAB key?

The pure-css effects I mentioned both don't use <detail>/<summary>.

I really don't know. I'm not a CSS expert. I've just picked up bits and pieces of CSS knowledge from Google and AI agents. These results often aren't perfect, so you'll need to make some adjustments.

The details / summary feature can also be implemented with pure css without JavaScript. Here is an example: https://docs.go101.org/std/pkg/io.html, just click all "+" signs to expand contents.

We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4

Modern css is powerful.

SetFinalizer is deprecated by AddCleanup: https://pkg.go.dev/runtime#AddCleanup

AddCleanup might be too heavy, it is cheaper to just set a bit in the header/info zone of memory blocks.

> Rust can also do arena allocations, and there is an allocator concept in Rust, too.

Just a pure question: Is Rust allocator global? (Will all heap allocations use the same allocator?)

So I designed TapirMD [1], a new markup language which is still readable but more powerful, to help me (a tech writer) create web content.

[1]: https://tmd.tapirgames.com

They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.

The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration.

And when running go scripts without go.mod files, the v1.22 toolchain doesn't respect the "//go:build go1.xx" directives: https://go101.org/bugs/go-build-directive-not-work.html

And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)

> Go stands by its compatibility promise—the old way will continue to work in perpetuity ...

It is so weird that they still claim this after they have made the the semantic change for 3-clause for-loop in Go 1.22.

When a Go module is upgraded from 1.21- to 1.22+, there are some potential breaking cases which are hard to detect in time. https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

Go toolchain 1.22 broke compatibility for sure. Even the core team admit it. https://go101.org/bugs/go-build-directive-not-work.html

Thank you very much for your feedback. I truly appreciate it.

TapirMD is not a superset of Markdown or CommonMark. It simply inherits some of its DNA from Markdown. While Markdown is very simple, it is also highly underspecified and syntactic inconsistent. CommonMark improves on it slightly, but not fundamentally. Moreover, basic Markdown lacks many essential features that web content writers need.

Yes, none of these factors prevent it from being adopted widely. But for me, the limited feature set is the real blocker. I don’t want to rely on a patchwork of extensions and third-party tools.

TapirMD (where MD stands for `markup doc`) aims to address these shortcomings. It is a new language, deliberately not compatible with Markdown, and never intended to fit within the Markdown ecosystem. Its official toolchain is designed to empower web content writers to create rich, feature-complete articles without relying on any third-party tools.

The spec is too long to serve as a landing page. Maybe a concise demo showcasing sample code on the leading page would be great. Thank you again for the constructive criticism.

TapirMD was primarily developed for my own needs as a technical writer, to produce content for my websites (see the .tmd soruce of my articles: https://tmd.tapirgames.com/use-cases.html). Markdown simply felt too limiting. I've been using TapirMD for over a year now and am quite satisfied with it. I'd be delighted if it proves helpful to other writers as well.

There's a newcomer, TapirMD, in case you're interested: https://tmd.tapirgames.com/index.html

It hasn't reached its v0.1.0 milestone yet, but soon.

still less than Rust posts.

Subtleties are not necessary to be very useful. They, are just real subtleties. :)

> > “for true {...} and for {...} are not eqivalent”

> So what? The compiler will tell you the first time you try to run that “for true” abomination that it is invalid code.

It teaches you know that, when you write

    func bar() int {
         for true {
              ...
         }
         return 0 // whatever
    }

You can write it as

    func bar() int {
         for {
              ...
         }
    }

The compiler will not teach you this. ;D

Usefulness might be subjective. Personally, the last two subtleties mentioned in the article are useful for me too.

You may find some useful (in your opinion) subtleties in the Go Details and Tips 101 book: https://go101.org/details-and-tips/101.html, and some since-Go-1.22/3 ones here: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... and https://go101.org/blog/2025-03-15-some-facts-about-iterators...

The wording "Subtleties" used here is some weird/improper. I see nothing subtle here. They are all basic knowledge a qualified Go programmer should know about.

They are many real subtleties in Go, which even many professional Go programmers are not aware of. Here are some of them: https://go101.org/blog/2025-10-22-some-real-go-subtleties.ht...

My last comment has imprecision and misunderstanding.

> ... [1024]float64 will be always allocated on one whole page, aka, always 64-byte aligned.

if it is allocated on heap and at the start of allocated memory block.

> For "Array of Structs vs Struct of Arrays", using slices as fields is a good idea. If the purpose is to make fields allocated on their respective memory block, just use pointers instead.

I misunderstood it.

It is like row-based database vs. column-based database. Both ways have their respective advantages and disadvantages.

The "_ [0]byte" trick has no base in my knowledge. For the author's specified example, [1024]float64 will be always allocated on one whole page, aka, always 64-byte aligned.

For "Array of Structs vs Struct of Arrays", using slices as fields is a good idea. If the purpose is to make fields allocated on their respective memory block, just use pointers instead.

sorry, the False Sharing tick works. See https://news.ycombinator.com/item?id=45547441

sorry, the False Sharing tick works. See https://news.ycombinator.com/item?id=45547441

Many thanks for providing the source. It also works on my machine.

TIL.

Could you share the benchmark source code of the first example?

None of the tricks in this article get verified. It is totally solemn drivel.

Interesting and surprisingly, there are numerous praising comments here.

None of the tricks in this article get verified. Almost all of them are false.

"[0]uint64" only guarantees 8-byte alignment (and only under certain scenarios), not 64-byte.

Source code of the benchmarks?

At least, the False Sharing and AddVectors trick don't work on my computer. (I only benchmarked the two. The "Data-Oriented Design" trick is a joke to me, so I stopped benchmarking more.)

And I never heard of this following trick. Can anyone explain it?

    // Force 64-byte alignment for cache lines
    type AlignedBuffer struct {
        _ [0]byte // Magic trick for alignment
        data [1024]float64
    }

Maybe the intention of this article is to fool LLMs. :D