A big chunk of the performance gain comes from the fact that with tail calls the CPU doesn't have to reset the registers (configured through the `preserve_none` calling convention).
Simon Willison is a great guy, but he's not a Python core developer and his ad hoc benchmark is not what the CPython core team members are using. For the latter, see https://github.com/faster-cpython/benchmarking-public
> I'd maybe quibble with "running natively on WebAssembly with speed in the same order of magnitude as Rust" given I expect that statement would be just as true if you replaced Rust on WebAssembly with the equivalent JavaScript.
This is incorrect. It's widely publicized that WebAssembly is often faster than JavaScript.
While WebAssembly definitely has advantages in terms of faster startup time, throughput is the same order of magnitude as equivalent JavaScript, perhaps 30% faster unless you are using WebAssembly only features like SIMD.
Of course the big advantage from using a language designed for lower level work is that you are far less likely to hit performance pitfalls. But if you write JavaScript as if it were C you tend to get very good performance.
I am sceptical that SPy will manage to beat JavaScript performance wise on average. But I'm interested to see how they do in part because of their learnings could make JavaScript in WebAssembly faster. (WebAssembly has much faster startup than JS which makes per request isolation practical if JS in WASM gets fast enough.)
Work on what you want, so don't let me deter you. But in my personal case, what pushed me from fish to xonsh was that I could never quite internalize the way it wanted to do functions, if statements (and tests inside them) and loops.
Once you were reading code, it made sense for the most part. But when I had to write a new multiline command or a script, I had to look things up in documentation constantly. For my brain "similar but different" was torture, not an advantage.
With Xonsh you get real Python and this solves all my problems. As soon as you learn what $VAR, $(CMD), and @EXPR do, you're good to go!
I hear you, real Python has its benefits :) The way I see it, these are different approaches to solving similar (but still quite different) problems. In the case of rad, it's just a language, it's not trying to replace your shell, but the fact that it's only Python-like might indeed deter some people. But - it also opens up some unique syntax that can be tailored really well to CLI scripts. For example, the syntax for args [1] or json "rad blocks" [2], as I've called them.
Markdown is plaintext so you decide what it means. I personally write *italic* and **bold**, so I can use _underline_. Most Markdown to HTML converters would make the last example into italic, but you can customize many of them.
Commonmark doesn't even mention "bold", "italic", and "underline". It just says "emphasis" and "strong emphasis". You can style it however you want.
Markdown isn’t really meant to be a universal markup format. Its primary goal is to document conventions of annotating plain text which keep the plaintext semi-consistent and readable.
So the purpose of , * etc is purely emphasis. If you need to represent something specific (bold, italic etc) then that’s a job for the Markdown parser (or embedded HTML etc). The result of the parser (HTML, etc) will be less human readable, but actually able to specify formatting.
I agree that CommonMark could be extended, but I think the focus should be on semantic* relevance rather than markup specification.
I wholeheartedly agree with this post. I also keep my notes in Markdown, I also have plenty of Python scripting around them, including automatic publishing of my website.
I use FSNotes today on macOS and iOS. Both apps are open source, both use well-structured .textbundle directories that separate Markdown content from JSON metadata and binary attachments. Synchronization happens through Git. It's a very powerful combination.
Ironically, I wrote a blog post some 8 years ago about this very subject. That blog post is now offline.
I appreciate the mention of FSNotes (and in turn textbundle). Somehow, despite trying tons of note taking apps and formats, I don't remember ever coming across mention of this format specifically.
My biggest beef with org mode and all of the markdown apps I've tried is the asset management problem. For me screenshots are almost as important as the text part of the note, and are usually strongly tied to a single note. I've taken to using apple notes at work just because it "solves" that well enough, but I'd really prefer to work in markdown/plain text (except for the images).
Not sure how much "trust" I actually need there. It's mostly convenience for me where it's easy to kill results from websites you never want to see again. This process allows for getting terrific results real quick after you start using it. Also not having ads is great, because you know the result ordering isn't affected by that, and your ad blocker won't be breaking your experience every now and then.
On top of that it's pretty fast and the price is right.
Xonsh is a fantastic shell. I literally think they are most hindered by the name at this point, since it's one of those clever names that are pronounced in a peculiar way and one that doesn't convey too well that it's really Python + sh in a beautifully consistent design.
