Bun, JavaScript, and TCO

https://www.onsclom.net/posts/javascript-tco

by tosh • 3 years ago

174 162 3 years ago

onsclom.net

sbarre3• 3 years ago

TCO in this article = Tail Call Optimization, not Total Cost of Ownership.

It makes the article more interesting!

gerikson• 3 years ago

It's also not Tjänstemännens Centralorganisation, the largest white collar union in Sweden, and also the org behind the TCO labelling of computer monitors.

sbarre3• 3 years ago

If you google TCO, at least where I am (North America), "Total Cost of Ownership" is the first result - and the dominant one on the first page of results.

It's also the main definition of TCO that most people are probably familiar with, me included.

This felt like a reasonable clarification to make.

smarx007• 3 years ago

Actually, as a chiefly Java/C# person, I was hoping for the article to cover how Bun helps lower the Total Cost of Ownership of Javascript projects by helping to get off the hamster wheel of infinitely deep npm dependency trees, wild west of constant project deprecations and major version releases with immediate deprecation of previous versions, daily game of CVE alert whack-a-mole etc. Preferably, short of writing all the code yourself.

sbarre3• 3 years ago

I also assumed the other TCO when I clicked through, which would have been an interesting take to read for sure (particularly since Bun is so new, so I was wondering how much data would be backing this analysis), but I'm not a strong functional programmer so any time someone covers functional-adjacent topics, it's interesting to me!

I'm with you on wanting to learn and explore more about Bun's main advantages though, the bundled tooling and some of the convenience APIs feel like well-planned time/effort/maintenance optimizations.

midtake• 3 years ago

[The tail call optimized] function is starting to look a lot like the orignal for loop solution. It’s not very succinct or elegant anymore.

(Brackets mine.)

I don't know about succinct but I definitely like how it looks a lot more. It's very readable, while the ternary operator one looks illegible at that length. It looks shoehorned in. It's the programming language equivalent of trying to mumble a whole sentence in two syllables.

k__• 3 years ago

Yes, every language should have if-expressions. Don't know what they were thinking with the ternary operator.

JonChesterfield2• 3 years ago

One reason I've heard for the statement vs expression distinction, where one deliberately makes a mess of the syntax uniformity, is that it helps diagnostics of programming errors.

That is, by demanding spurious restrictions on syntax and generally making code more annoying to write, you get to detect more constructs as probably bad.

Line noise - semicolons in C, colons in python - is the same idea. Earlier diagnostics of code that probably wasn't intended.

I don't find this remotely compelling as a language design choice but it's the best justification I've come across for why so many have the extra obfuscation between programmer and AST.

Specifically, why would one optimise for ease of reading invalid code instead of for ease of reading valid code. Madness. But popular.

recursive• 3 years ago

How are if-expressions different from the conditional operator? I thought one was a concrete implementation of the other.

nsonha2• 3 years ago

ternary is not the important part here, could write it with if and early return too.

imjonse2• 3 years ago

It's nice, but the downside is that relying on TCO can make your Bun-tested code unexpectedly break with stack overflow error if it ever gets run on Deno or Node. So probably a good idea to comment this part of the code and make sure if it's in a library to similarly warn the callers somehow.

bryancoxwell• 3 years ago

Does serverside JS have anything similar to #ifdef?

vlovich123• 3 years ago

Yes. You can define a constant (eg IS_SERVER) which your bundler (eg esbuild) replaces with a specific value depending on what environment you’re targeting. There are also ways to detect it using runtime globals that are only defined within the browser although that can be monkeypatched by your own code or 3p libraries you import (not common but could be a compat layer you add to make server side JS behave more like a browser).

antipurist• 3 years ago

Something like

    if ('Bun' in globalThis) ...
    if ('Deno' in globalThis) ...
    if ('window' in globalThis) ...

could be used to determine the runtime.

quickthrower23• 3 years ago

Yes the O is more than an Optimisation, it is a change in semantics.

pcl• 3 years ago

Recursion takes up precious memory on the call stack! There may be commands to increase the call stack size for your program, but there is only so much the OS will allow. Memory on the heap is much less restricted.

This reasoning implies that tail call optimization is some sort of memory-segmentation workaround. This isn't accurate.

A (non-TCO) recursive approach is more expensive because it uses O(n) bookkeeping memory, whereas the iterative approach uses O(1) memory. Naive recursion will allocate a stack frame for each "iteration", whereas the loop approach will not allocate anything per iteration.

So, the iterative approach simply uses much less memory for large iteration counts; the placement of the memory in stack space or heap space isn't the relevant factor.

fyrn_• 3 years ago

But without TCO, even if your function doesn't have any state of it's own, it will use memory on the call stack. I don't think anything about what they said implied memory segmentation was the problem. It's pretty clear they mean each recusion increases the size of the call stack without TCO.

rezonant• 3 years ago

Agreed, I think the mention of heap space was more to answer the question of someone new to this topic of "but wait, I can allocate gigabytes of data in an array, why can't I allocate 100,000 stack frames?"

brabel5• 3 years ago

The performance difference is not just about TCO, but about creating a new array on each iteration instead of reusing the old one... in Lisp, because it uses cons cells which share structure, appending is very efficient, so the recursive code runs as fast as it can get... not so much with JS arrays.

pjmlp8• 3 years ago

Even in Lisp, if performance matters there are other data structures.

We are decades away when lists were the only option.

brabel5• 3 years ago

In the example in this blog post, I am quite certain plain LISP lists would still be the right choice today.

odyssey77• 3 years ago

ECMAScript continues to evolve and I suspect that there would have been an effort to make the spread operator into a sort of cons in JavaScript. It could have worked for both arrays and objects. However, after seeing that the entry-level bar of proper tail calls couldn’t make it out the door for Chrome and V8, they might have decided not to push it and risk further divergence from a major implementation.

ColonelPhantom• 3 years ago

Isn't prepending the efficient operation? Appending would require mutation or copying, prepending only requires a single new cons cell.

Appending to a linked list is fine if you can mutate and keep a pointer to the tail, but then again, extending mutable arrays is also amortized O(1) assuming a reasonable allocation scheme.

brabel5• 3 years ago

The common pattern in LISP is to prepend using cons and then reverse the list at the end if order matters.

Check this program as an example: http://www.norvig.com/java-lisp.html

Recursion is done with `(cons (nth-digit digits start) words)` and recursion ends with `(format t "~a:~{ ~a~}~%" num (reverse words))`.

JonChesterfield2• 3 years ago

TCO should be table stakes. An interpreter can do it by noticing that the next thing is a call to itself (the interpreter), a compiler by reorganising the stack frame before the jump.

Lots of stuff gets in the way. Destructors, varying type signatures, calling conventions. But for the case where it can happen, it should be considered an implementation error that it does not. Very like a space leak.

edit: this ^ was evidently unclear - tail call support in an interpreter means recognising when the interpreter is about to call the interpreter and jumping there, e.g. in an eval-apply setup, you use one frame for the eval-apply-eval-apply skeleton and only spawn more for evaluation of function arguments.

Tail call support in an compiler involves changing the calling convention to clean up before jump. At that point it's all jumps, whether back to the top of a loop or to some other basic block, because all the world is SSA to a pretty good approximation.

Neither of those makes any meaningful distinction between calls-to-self, calls-to-sibling, calls-to-indirect and so forth. The TCO is easier on self calls idea comes from languages where it is hacked before the compiler backend in a setting where goto isn't allowed to cross function boundaries. Some C code will have a label at the top named "self" or similar and use `goto self;` to force the equivalent of a tail call, some compiler stacks implement TCO by a mechanical version of the same hack and thus can't deal with it crossing between different functions.

edit2: If you're compiling to a target with restrictions on calling convention that preclude cleanup before jump (and doesn't sort this out itself) you are out of luck. Pick a better target or live in the doomed world you've created. See e.g. https://v8.dev/blog/wasm-tail-call for some stuff on wasm trying to fix itself, I haven't kept up to date with whether they did or not.

anonymoushn4• 3 years ago

TCO is broader than tail calls to the same function, but tail calls to the same function would certainly be a start.

vitus• 3 years ago

TCO is about more than self-recursive calls -- you should be able to handle mutual recursion:

    f = x => x > 0 ? g(x - 1) : 0;
    g = x => x > 0 ? f(x - 1) : 0;

(These functions don't do anything other than stress-test the stack, then return 0.)

Note that if I changed this to, say, 1 + g(x - 1), this would no longer fall under the purview of tail recursion, where the last instruction before the return is a recursive call.

The usual workaround I learned in my SICP days was to add a second variable for accumulating any results. And, indeed, that's how the blog post rewrites the recursive function.

(The recursive one-liner is still wildly inefficient because JS doesn't implement arrays as linked lists, so the spread operator results in a copy for each recursive call, resulting in a quadratic solution. It could be made more efficient by using Array.prototype.push, but then it's no longer a pure function.)

runarberg3• 3 years ago

I don’t think they picked the best example to showcase this, most JavaScript developers would write this simply as:

    Array.from({ length: n }, (_, i) => i + 1)

But this example does get the point across, so I think it is fine. I do agree though, while reading it the inefficientness was screaming at me.

djur4• 3 years ago

Implicit tail-call elimination outside the context of tail-recursive algorithms causes behavior that is surprising to programmers working in languages where stack traces are used for debugging (i.e. it removes frames from the stack and obscures the path of execution).

leeoniya2• 3 years ago

the reason TCO is not implemented in V8, iirc, is because of developer experience and needing devtools to faithfully dump the call stack that hasnt been flattened, because that's what's expected of js DX.

does JSC's implementation solve this? do they exhaust the stack only when devtools are open, or smth? maybe they just keep the last 10 frames in memory for devtools? (that would make most sense to me)

pjmlp8• 3 years ago

This is a solved problem on programming languages where it is part of the specification, like Scheme.

Basically the debugging info and what actually happens isn't 1:1, rather the logical model of the execution.

twic• 3 years ago

What is the solution?

anonymoushn4• 3 years ago

This is a silly justification I think, in the sense that V8 could implement this in a way that can provide stack traces for all stacks that are short enough for a human to browse while also executing programs that use tail calls as goto correctly.

hajile11• 3 years ago

Nobody cares that loops don’t have stack frames. Few people cared for decades that async functions lost stack traces.

It’s just a bad excuse.

leeoniya2• 3 years ago

touché

deredede2• 3 years ago

See [1] (Filip's commit message introducing ShadowChicken is also quite well written if a bit more technical [2]).

[1] https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-...

[2] https://bugs.webkit.org/attachment.cgi?id=274533&action=revi...

MrJohz8• 3 years ago

I think this article actually does a really good job of explaining why TCO hasn't really been an important part of the JS ecosystem.

There's a lot of situations where recursive algorithms are really neat and clear. I don't know if this is the best example, but it shows the benefit of being able to split logic into a base case and a recurrence case.

But, in my experience, an algorithm that elegantly fits a recursive relationship is rarely one that naturally fits the tail-call paradigm. Often part of the benefit of recursion is that you can store state in the stack - the very thing you need to avoid to use TCO.

This means you often need to put in effort to create a tail recursive algorithm. But that often ends up looking a lot like the imperative case anyway - an accumulator outside the loop that you either mutate manually, or update in a tail call. And in my experience, the mutating, imperative version is usually then the easier to read and write (assuming you can keep mutations to a given scope, and not have that state leak all over the place). (In fairness, this might be more familiarity, though.)

In the light of this, what is the advantage of TCO? In functional languages without mutation, it's pretty important to allow for functions to act on arbitrarily-sized inputs without constantly growing the stack. But if we have mutation, it's really just a different way of writing the same code. And if that different way is generally less clear and almost always less performant, it probably isn't a very useful choice.

Which is why I think TCO hasn't really caught on in the other JS engines. It's a cool idea, and there's definitely a handful of cases where it's the useful way to go, but usually you'll be better served by writing things in the more traditional JS way.

pjmlp8• 3 years ago

Regardless, it has been approved as part of JavaScript specification and Chrome folks refuse for political reasons to implement it, which given the market domination everyone has helped them achieve is a bummer.

MrJohz8• 3 years ago

Firefox have also chosen not to implement it, right? Indeed, my impression was that Firefox were far more against the whole thing than Chrome, who did implement TCO but then removed it for various reasons.

My impression is that this is less an issue with any particular implementor, and more with the feature not being fully thought through at the beginning. A lot of the browsers (including the Edge team at the time) ended up running into issues, on top of the UX/explanatory problems. That's why there was the alternative proposal for explicit tail calls, but those didn't go anywhere.

tomashubelbauer• 3 years ago

I find it surprising that the JS specification also includes optimizations an engine should implement. I'm not sure how difficult TCO is to implement, but I just checked if QuickJS supports it or not and it seems to be one of the few ES2020 omissions the author chose to make: https://bellard.org/quickjs/quickjs.pdf (3.1.1). This tells me it might be non-trivial to implement which if true makes the decision to make it a part of the specification all the more surprising, because that means the specification restricts the types of trade-offs implementers can make when attempting to achieve full compatibility. In other words, until today I was under the impression you could make a fully ES compatible engine, but choose to make it slow for implementation ease. Looks like the spec defines the floor for how (non)-performant the engine implementation can be in some cases. Is this common in other languages' specs?

Edit: Oh, seeing the sibling comment, are TCO and "tail calls" different things? If so, I remain unclear on the status of TCO support in QuickJS.

spankalee• 3 years ago

What "political" reasons?

My understanding of the situation is that it's entirely technical issues that came up after implementing.

odyssey77• 3 years ago

I don’t think the example is particularly good. TCO is essential in functional programming, where recursion shines, but the example given is an impure function which mutates its input parameter by calling Array.prototype.push. Basically, this isn’t a demonstration of the paradigm for which TCO is required.

We’ll never know how big of a role TCO could have played in JavaScript over the past several years, because it hasn’t been available outside of some narrow contexts.

MrJohz8• 3 years ago

I agree that TCO is essential in functional languages where loops and mutability are disallowed or at least heavily discouraged, but Javascript is not one of those languages. In Javascript, both mutation and and loops are very simple, and as I think the article demonstrates, often the clearest ways to express an idea.

Where recursion is clearer (for example, when dealing with recursively nested data structures), the clearest expression of a function usually isn't tail recursive - that often requires rewriting the function to put more state into the function arguments.

This means that tail recursion rarely matches with patterns used regularly in Javascript. That's not to say it's useless - if you want to keep to a particular functional style, or if you're compiling to Javascript from a language that emphasises recursion, then it's a useful tool to have. But in the former case, you're generally going to struggle with browser engines not being optimised for this style, and in the latest case, you're probably better off targeting WASM directly.

o11c• 3 years ago

The real problem, of course, is that in the cases where compiler-based TCO is possible, the user can trivially refactor the function to use a loop.

tikhonj• 3 years ago

Tail calls also matter for code in continuation-passing style (CPS).

This matters for some styles of programming (callbacks/promises/monads/etc), but it's also very useful for code emitted by compilers and DSLs. It's much easier to encode complex control flow with CPS than just with the basic constructs JavaScript supports.

Even for hand-written code it can be pretty important. It's easy to imagine rewriting simple tail-recursive functions in an imperative style, but it quickly gets much harder, especially if your problem naturally decomposes into mutually recursive functions: that is, instead of a function calling itself, you have multiple functions calling each other, often with a bunch of additional computation between each call. I've run into this when writing parsers as well as custom algorithms for constraint-satisfaction kinds of problems. (Which are pretty common!)

tonyg2• 3 years ago

an algorithm that elegantly fits a recursive relationship is rarely one that naturally fits the tail-call paradigm.

That's because tail calls are structured gotos (with arguments). They're not really about recursion or even iteration.

what is the advantage of [proper tail calls]?

There's a loss of expressiveness [1] without them, similar to the loss of expressiveness when there's no garbage collector.

if [using proper tail calls] is almost always less performant, it probably isn't a very useful choice.

Don't assume PTC is less performant. There's no intrinsic reason for it to be. After all, the machine should be doing (slightly) less work: a goto instead of a call. Retrofitting it to an existing system can of course lead to a poor implementation, but it is not inherently a slow construct.

[1] Felleisen, Matthias. “On the Expressive Power of Programming Languages.” Science of Computer Programming, vol. 17, no. 1--3, 1991, pp. 35–75, https://doi.org/10.1016/0167-6423(91)90036-W .

MrJohz8• 3 years ago

To be clear, I'm not talking about PTC/TCO in general in this comment, I'm talking about it specifically in the context of Javascript, and in the context of the common patterns of Javascript usage.

That is, PTC doesn't just need to be powerful than other forms of call, it needs to be more useful day-to-day than other ways of writing the same logic. I think this article shows that, at least with the common recursive examples, that's rarely the case - it is pretty much always clearer and significantly quicker to use loops and Array methods than it is to rely on PTC and recursion.

You make a good point that there are uses for PTC outside of recursion, and that there are things you can do with it that can't be done with existing constructs. I'm sure that's true, but in my experience, the things people want to do with these tools tend not to fit well with the other features of Javascript, such as the high degree of mutation, and the dynamic nature of the language. At which point, it's probably more useful to create a compile-to-Javascript language instead that uses these sorts of features internally.

But with the rise of WASM (which has PTC as a proposal that I believe some groups have already implemented), it makes a lot more sense to use WASM as a target instead. There, you have a lot more control over exactly what gets executed and how, along with generally smaller and faster code. The exception right now is obviously DOM manipulation, but with the GC work being done right now, the path is opening up to getting easier access to the DOM directly in WASM.

akoboldfrying2• 3 years ago

I think this article actually does a really good job of explaining why TCO hasn't really been an important part of the JS ecosystem.

Nicely put. TCO is a bit like a guitar solo: more fun to implement than it is useful/enjoyable to the intended recipients.

quickthrower23• 3 years ago

Is it just me but I never use recursion in JS (or imperative languages generally) and it never really comes up as a need?

jiehong• 3 years ago

We’re using recursion at $company to validate user inputs because it’s a user-defined tree of unknown depth.

anonymoushn4• 3 years ago

For example if you write a json deserializer that's generic over the struct you want to deserialize to (or one in JS that returns a JS object), you'll usually use some sort of recursion. My generic radix sort[0] also has recursion in it, which seems like the most straightforward way to write it, but of course any recursive function could be mechanically converted to one that does not use recursion.

[0] https://github.com/alichraghi/zort/blob/main/src/radix.zig#L...

odyssey77• 3 years ago

Nitpick: JS is multi-paradigm.

quickthrower23• 3 years ago

Yeah I should have been more specific. I mean languages where recursion is idiomatic for many problems because the language is purely functional like Haskell.

kosolam• 3 years ago

This isn’t a good thing if your fancy recursion code works great on bun but is slow in other js runtimes.

anonymoushn4• 3 years ago

Seems fine if you actually run it on bun.

imjonse2• 3 years ago

Related: Guido van Rossum's argument for why there is no TCO in Python.

https://neopythonic.blogspot.com/2009/04/final-words-on-tail...

Jarred3• 3 years ago

(I work on Bun)

A neat thing about tail calls in JavaScriptCore: there’s an explicit bytecode intrinsic for it.

  return @tailCallForwardArguments(MyConstructor, this);

To use this in Bun, you’d have to start Bun with the environment variable “BUN_JSC_useDollarVM=1” and then $vm.createBuiltin(mySourceCodeString)

When using this intrinsic, if any of the arguments are incorrect or it cannot otherwise enable it, the entire process will probably crash. In debug builds of JSC it will have a nicer assertion failure but that is not enabled in release builds

Example code: https://github.com/WebKit/WebKit/blob/17351231b4dedb62d81721...

also happy to answer any questions about Bun

CodeGroyper2• 3 years ago

Love bun, thank you so much Mr. Sumner.

What is the priority of app router integration for NextJS?

johnfn• 3 years ago

What is the priority of app router integration for NextJS?

I'm not Jarred, but what do you mean by this? I'm using bun + app router + NextJS and everything seems to work just fine.

Jarred3• 3 years ago

After Windows support is further along, but not that long from now

leptons• 3 years ago

When do you see AWS Lambda supporting Bun, if ever?

Jarred3• 3 years ago

You can use it today with containers in Lambda or a custom Lambda runtime, but both approaches have embarrassingly slow cold start. Lambda has special optimizations for Node which are not possible without official support.

I have no idea when Lambda would add an official runtime layer. But if you work at Lambda and are interested, feel free to email me - jarred@bun.sh

magic_man• 3 years ago

You can use a loop and a stack and can get recursion without adding all the overhead of a function call.

refulgentis• 3 years ago

I spent the first year or two of my career thinking I needed to Do Recursion because thats what the textbooks said and hey, the language supports tail calls!

I learned, in the sense you learn by touching a hot stove, that:

A) you can't guarantee the compiler sees it as a tail call and optimizes it.

B) you are now open to a stack overflow appearing in your software at any given point due to compiler changes / your own changes that confuse the compiler, etc.

C) qed, don't do tail calls.

kriiuuu• 3 years ago

Both Scala3 and Kotlin allow you to annotate functions with @tailrec which will give you a compiler warning if the compiler can’t optimize. And if you use the xfatal-warn compiler flag the Scala code won’t compile if your function is not tail call.

FpUser• 3 years ago

"I spent the first year or two of my career thinking I needed to Do Recursion because thats what the textbooks said"

Being an old fart I've learned long ago to not follow self declared prophets. Recursion is a trade off that comes with the cost. Sometimes it makes sense to use it and sometimes (most of the times) it does not. You do what makes you and your customers happy.

timw4mail2• 3 years ago

Iterating over tree structures is a pain without recursion, but that's the only situation where I feel I need recursion.

ivancho• 3 years ago

I don't think you can use tail call recursion for tree walking unless you also manually maintain another stack. And at that point iterative code looks just as readable

chrismorgan2• 3 years ago

This is not actually about Tail Call Optimisation, which is more flexible and optional matter of optimisation, but about Proper Tail Calls, which are a guarantee made in the ECMAScript 6 specification (over implementer concerns objections)—in strict mode, calls in tail position must not create additional stack frames. This is the last piece of ECMAScript 6 that most engines haven’t implemented, because it’s rather controversial: it actually causes some performance problems, and makes debugging harder, and may have security issues (in 2016, Mozilla declared it impossible to implement across realm boundaries due to their security model).

https://github.com/tc39/proposal-ptc-syntax has a lot of useful information about it all, and a proposal to make it explicit in syntax, such as with `return continue …`, though I don’t believe that’s really gone anywhere. The practical situation is that this is the one part of the ECMAScript spec that most implementers ignore, and thus which you can’t depend on. Which says to me that it should either be made optional or be removed from the spec. Not sure if there are any other features similarly disregarded. ECMAScript specification policy was different in those days, they operated more independently of implementers. (HTML was like that once too—that’s roughly why WHATWG was formed, because the actual implementers weren’t happy with how things worked in W3C, so they took matters into their own hands.)

(Fun terminology problems here. The term TCO is commonly used for PTC, and PTC is very close to being a subset of TCO, but the mandatory stack frame elision which ruins debugging feels to me like it falls outside of TCO. In various situations, debuggers will mark things like “stack frame omitted” when they’ve optimised one out of existence, but you can generally compile things differently, or something like that, to prevent this. (Compiled/dynamic language variation showing up here.) But with PTC, it feels like the engine is kinda not even allowed to know that a stack frames may be absent. So I say PTC and TCO are a little distinct, though PTC is mostly just a subset of TCO. Reminds me of the terminology of tree-shaking versus dead code removal—where the former is essentially a subset of the latter, but that the effects are just slightly different, though I’d say it’s more slight in that case than this.)

65• 3 years ago

So the optimization here is that instead of creating a new array every time you call the count function recursively, you're only modifying a single array. Thus the new array recursive function is significantly slower because we're storing all those arrays in memory when calling the count function recursively. Do I have that right?

snissn• 3 years ago

I gave bun a test with react apps and found that it installs node_modules much much faster, but starting up a react dev server took the same time

jart2• 3 years ago

TCO is cool. I remember how enlightening it felt when I studied Scheme and came to understand how it's implemented there.

deredede2• 3 years ago

If this is not what you're referring to, you might be interested in CHICKEN Scheme's implementation, which is unlike any other I've seen: instead of compiling tail calls to jumps, they are just regular calls, and the call stack is effectively garbage collected when it would overflow.

jtlasdfjwfasdf• 3 years ago

Agreed. Scheme taught me that function invocations didn't have to be sullied with the risk of stackoverflow, and in-fact what appeared to be recursive was actually iteration and loop constructs were not needed.

mwkaufma• 3 years ago

Optimization and functional recursion is nice and all, but the unsung killer-feature of (mandatory) TCO is to (ab)use the stack as a state-machine. Each "state" is a function which tail-calls the next state, so it replaces the stack frame. Stack-traces now double as state-inspectors. Substates naturally follow from subroutines.

I regularly use this in Lua gameplay scripting, which has proper tail-calls in the language spec, not just as an implementation-optional detail.

koito17• 3 years ago

Languages that rely on recursion like LISPs often specify that TCO must be implemented in their language spec.

This is inaccurate. As far as I can tell, it's only Scheme specifications like r5rs that have a hard requirement on tail-call optimization. The Common Lisp specification makes no mention of tail-call optimization, and Clojure -- arguably the most widely used Lisp today -- does not have it either (but it has special forms and macros that let you write recursive code and produce trampolines, thunks, etc. to avoid blowing up the stack).

With that said, at least in the case of Common Lisp, it is true that many compilers will implement TCO, even though it is *not* required at all to conform to the specification.

lispm3• 3 years ago

Common Lisp is not a Lisp which 'relies on' recursion. It has various loop statements (DO, DOTIMES, DOLIST, ...), various mapping functions (map, mapcar, mapc, maphash, ...) and a complex LOOP. To prevent stack overflows those can all be built on top of a goto operator (tagbody + go). One of the reason was that compilation targets (cpus, virtual machines, other languages, ...) don't have native TCO support. For example the various Lisp Machines had no TCO support, and many C compilers did not support TCO for quite some time. C is a popular compilation target (KCL, AKCL, ECL, CLASP, CLICC, ... were (some are) all Lisp to C compilers).

With that said, at least in the case of Common Lisp, it is true that many compilers will implement TCO, even though it is not required at all to conform to the specification.

The specification does not require it, it actually says nothing about it. TCO isn't even mentioned. Means, it also says nothing how a compiler should support it, if it wanted to. The language supports recursion, but something like tail recursion support is entirely an implementation specific optimization. Since TCO has some advantages (less stack space needed, possibly some faster loops, ...), many compilers implement it, but mostly no interpreter does it.

Also, most of them support GC, even though exactly nothing is said about it in the specification. ;-)

reactordev7• 3 years ago

Not to be a dog in the fight but…

How is:

   const count = (amount: number) => (amount > 0 ? [...count(amount - 1), amount] : []);

Succinct and better? It’s fewer lines. It uses recursion. But it’s obtuse and illegible syntax diarrhea that takes more time to grok.

The for loop example above, while simple, is easily understood. A junior engineer could fix it. Is it faster? No. Is it easier to understand? Yes. I like the final example as well.

Look, I’m all for being clever when cleverness is needed but some of you JS/TS folks take it to the extreme. I want to be able to read my codebase, not perform archaeological studies. I have the same issue with Rust syntax as well in places.

I will praise the article on this though, optimizations do matter and having something execute orders faster will improve your overall experience. It doesn’t have to be cuneiform. If you must be clever, wrap it in an abstraction that is well documented because you don’t live forever and neither will your code, make it easy(ier) on the next person. While you can nest a recursive function in a tertiary statement coro, don’t. Fire is cool but also burns.

Btw, bun is blazingly fast. I look forward to more.

mhink• 3 years ago

Look, I’m all for being clever when cleverness is needed but some of you JS/TS folks take it to the extreme.

To be fair, this is very much a toy example meant to demonstrate tail recursion- although I do agree it's not a great example considering you need to understand the evaluation order of ternaries in order to understand why one version is tail-recursive and the other isn't.

That being said: generally speaking, one might argue that using recursion at all is "too clever" and algorithms should just stick to iteration altogether. ¯\_(ツ)_/¯

While you can nest a recursive function in a tertiary statement coro, don’t.

Man, why do you gotta call me out like this? :D

akoboldfrying2• 3 years ago

algorithms should just stick to iteration altogether

Well, if your algorithm performs 2 or more recursive calls per function invocation (like, say, quicksort), at least one of them needs to be an actual recursive call that uses additional stack space, since TCO is only able to mitigate a single recursive call per function invocation. (You could simulate your own stack and use iteration... but the only reason to do so in practice would be to escape some artificial restriction on native stack size.)

reactordev7• 3 years ago

”Man, why do you gotta call me out like this?”

Because you lose the stack trace most of the time. Only God and you know where the Uncaught PromiseRejection happened. It’s just really hard to debug when things go south. This drives me bonkers with the AWS sdk.

satvikpendem2• 3 years ago

If one is well-versed in functional programming, they would understand the above function just fine, plus it comes with all the benefits of functional versus imperative styles, which I will not repeat here as there are lots of articles on this. Perhaps JS devs should spend more time in functional codebases rather than imperative ones and they'll also get used to such code, and I for one am glad to see TCO making this style more efficient compared to traditional for-loops.

djur4• 3 years ago

This style isn't efficient in JS, though, because it produces a ton of garbage to collect. TCO doesn't really make it more efficient, just possible.

cowsandmilk• 3 years ago

Perhaps JS devs should spend more time in functional codebases rather than imperative ones

the pure functional version takes 700x longer to run than the imperative version; maybe the wins of functional programming just aren't there in JS engines today.

reactordev7• 3 years ago

If one was well-versed in memory management and how the stack would blow up in production one would not have to repeat them here.

Also, if you have to justify cleverness, it’s not clever. Don’t defend the style by grandstanding on “functional is better” or “you don’t know func bro”, how about ask why I feel the imperative style is more legible? Why would this not be the best way to write this? Where can I write this way? Or even “I find this style to be legible to me, but I’m curious about why you think it’s not”.

kannanvijayan3• 3 years ago

I’m surprised no one has brought up the fact that this code has quadratic time complexity when the underlying algorithm could be linear.

And the fact that it’s allocation behaviour is horrible, leaving behind ‘count-1’ garbage objects, count-squared garbage memory, and forcing the GC to chase after the algorithm.

I can accept this example as a contrived scenario to talk about TCO… but even in the presence of TCO one would not want to implement the function this way.

djur4• 3 years ago

The article doesn't explain why (and it should) but it does mention that this version is very slow and offers a version that doesn't have the same problems.

reactordev7• 3 years ago

I wasn’t even going to dive into the allocations and garbage this style brings but it’s orders of magnitude slower, with more garbage created, disposed of, than a simple if statement. I’m glad you opened the can of worms. There are times when this doesn’t matter. Reading a config json, or performing your startup bootstrap, but if this was executed during a request or during a frame then you’re going to have a bad time.

nsonha2• 3 years ago

looks linear to me? Takes n calls, each is O(1).

the fact that it’s allocation behaviour is horrible, leaving behind ‘count-1’ garbage objects

Topic is TCO, which is kinda about that.

mitt_romney_12• 3 years ago

If you replace the ternary with an if then it's easy to understand for anyone who knows what ... means (which imo every JS developer should know)

  const count = (amount: number) => {
    if (amount > 0) {
      return [...count(amount - 1), amount]
     } else {
      return []
     };
  }

reactordev7• 3 years ago

You missed the point entirely I’m afraid. It’s not about replacing the if with …, it’s about complexity.

femiagbabiaka• 3 years ago

The ubiquitousness of c-style makes it more familiar. But that doesn't make it better syntactically. And of course what's faster or more memory efficient is an implementation detail ultimately, but moving away from the imperative style opens up the opportunity for new and interesting -- and potentially more grokkable, ultimately -- patterns. Rust is actually a great example of this, with things like match and pattern matching.

Don't be such a language grinch.

reactordev7• 3 years ago

Talk to me about lifetimes of Boxed RC Mutex then… because last time I checked, I had to do some insane amount of <T> to get a concurrent collection synchronized. I’m all for functional. Just don’t over use it in places where a simple function would suffice and try not to use it when dealing with recursive allocations of temporary arrays. Rust has come a long way but I feel like some of their style choices were to feel superior rather than make something functional. Go is a great example of simple, functional, but not quite as robust - as Rust.

cj• 3 years ago

Based on the title, I was hoping for a TCO (Total Cost of Ownership) analysis on Bun/Javascript.

Or the cost of running a company’s architecture on a “new” (not really new, but quickly evolving re: frameworks) JavaScript.

qudat• 3 years ago

While working on effection@v3 (https://github.com/thefrontside/effection) we spent a bunch of time ensuring that our delimited continuations could handle deep recursive call stacks in Deno.

PR: https://github.com/thefrontside/continuation/pull/11

TCO would have definitely simplified this issue.

What’s worse is hitting maximum memory callstack exception is very tricky to catch and is not reliable across runtimes. So when a user hits it it can be tricky to track down.

Bun, JavaScript, and TCO

Related Stories