It is indeed.  I&#x27;m in the process of porting from Racket to Lumen.  It&#x27;s taking a bit, and it&#x27;ll be tricky to add true greenthread support to js and lua, but it&#x27;s a win so far.<p>Wart is freaking cool!  Thanks for showing that.  Whoaaa, you use tangle&#x2F;weave!  How do you like it &#x2F; what do you think about literate programming?  I was batting around the idea of writing code that way, but it seemed like tangle might not be the best solution.  But I love your 000prefix naming scheme; I instinctively do that for branches.  After reading through a few files starting at <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;master&#x2F;literate&#x2F;000organization" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;master&#x2F;literate&#x2F;000org...</a> it became pretty clear how wart worked, pretty quickly.  I&#x27;m mainly wary of the &quot;compile&quot; step that using Tangle implies; do you find it slows you down much?  Would you choose to do it that way if starting fresh?<p><i>What would a language ecosystem be like without any backwards-compatibility guarantees, super easy to change and fork promiscuously?</i><p>It&#x27;s fun to find someone has been mulling over the same problems!<p>I was considering taking Laarc in a similar direction:<p><pre><code>  (import &quot;akkartik&#x2F;foo&quot;)
</code></pre>
That would check whether the folder &quot;..&#x2F;foo&#x2F;akkartik&quot; exists, and if not, clone foo from github.com&#x2F;akkartik&#x2F;foo.<p>It would also rewrite its own source code to look like:<p><pre><code>  (import &quot;akkartik&#x2F;bar&quot; &quot;f1d2d2f924e986ac86fdf7b36c94bcdf32beec15&quot;)
</code></pre>
That means whenever someone clones your codebase, running the program would cause them to clone github.com&#x2F;akkartik&#x2F;bar using commit f1d2d2f9.<p>So it&#x27;s static linking, basically.  It&#x27;s a guarantee that &quot;This source code will always work, the same way (+ 1 2) will always yield 3.  You could copy-paste this source code into a gist, and whoever ran it would end up running the same program.&quot;<p>That removes dependency hell &#x2F; worrying about versions entirely.  But it&#x27;s not the right solution, and I&#x27;ve been searching for a better one.  What do you think?<p>The problem is that it throws away the ability for the code to pull updates from library maintainers.  If the import is &quot;pinned&quot; at commit f1d2d2f9, then you push a security-related patch to akkartik&#x2F;bar, most existing code will stay vulnerable forever, because most code is never maintained after being written.<p>I was thinking of following that model, but using the convention that libraries are expected to use git tags in order to indicate major.minor.patch, and (import &quot;akkartik&#x2F;bar&quot; &quot;f1d2d2f924e986ac86fdf7b36c94bcdf32beec15&quot;) will bump itself to the next commit if it&#x27;s tagged as an increment of the patch version.<p>What kind of things have surprised you about Wart during development?  Any unexpected pitfalls or interesting discoveries along the way?  Thanks again for pointing it out!<p>By the way, were there any ambiguities with indentation-as-parens?  I haven&#x27;t thought about it rigorously, so I was just wondering if there are any corner cases to watch out for when I add it.