The concepts of internal DSLs and external DSLs is relevant here. The article is an internal, to Python, DSL. It runs in the language the tool is written in. Mermaid is an external DSL. You can’t build a Mermaid renderer in Mermaid. For diagrams I’d rather have an external DSL or a macro system than an internal DSL because it looks cleaner IMO. But it’s nice to have syntax highlighting already working in internal DSLs.
I am developing a Pythonic alternative to ArgoCD and FluxCD that uses no CRDs or in-cluster controllers for continuous delivery of applications to Kubernetes clusters
Google inexplicably killed the Chromecast Audio as well, and it was an absolutely perfect device for a very particular niche (streaming audio to an old stereo/amplifier without needing a permanently connected phone as is the case for Bluetooth).
I hope mine still lasts for a long time (I believe there are some Google-signed certs on it that might expire some day?).
OMG! No! Having dealt with Go templates in the context of writing Helm charts, I would say this is not a a great idea. Please, invent a better templating language for Go, and then perhaps go down this path. That being said, I am not a great fan of templates in any language. Jinja2 might be a heck of a lot better than Go templates but it can still be hard to get right.
What is so wrong with this approach that makes you exclaim "OMG! No!"? This is practically no different to any basic server side rendering framework in any other language. This is a very basic pattern used all the time.
There is no protecting against pre conceived notions. If a Typescript programmer, for example, expects Python to behave like Typescript then that is on them. Typescript has types. Python has type hints. RTFM for God’s sake.