Hacker News Reader

Comment by giorgioz | Hacker News Reader

What's the term used for tree shaking outside JS? Do Java or Python or Ruby or PHP do something as advanced as tree shaking? Having migrated a whole company from Java to JS I know that the JS ecosystem is very large and birthed incredible tools that are lacking in other languages/playgrounds. webpack is an incredible builder compared to what's available for Java/Kotlin on Android and Swift on iOS. And webpack just got blown out of the water from esbuild. So my hypothesis (until proven wrong with links) is that the other languages never really reached the awesomeness in tooling when tree shaking is done.

View on HN

It’s called Dead Code Elimination in the context of an optimizing compiler. Both GCC and LLVM have supported naive versions for a long time; more recently, Link-Time Optimization has allowed both to fully prune functions that can’t be called by the program.

I don’t know about PHP, but both Python and Ruby have module/import semantics that explicitly allow functions to be smuggled across “visibility”/access boundaries. So they can’t really do this sort of optimization, at least not without breaking a whole bunch of real code.

I also forgot to mention: these sorts of optimizations probably aren't very effective on Ruby and Python anyways. Compiled code benefits from DCE because it simplifies control/call flow and decreases instruction cache pressure, while JS benefits from it because it decreases the amount of text you're serving over the network.

Python and Ruby are aren't going to benefit (much) from the former and the latter doesn't apply, which is probably why it hasn't been a priority in either language.

Server-side programming languages and apps do not need to optimize "bundle" size as JS need to because client downloads (expensive and slow to download large js file as most internet usage now is via mobile phones) and executes the code (also slow as it need to be done on client every time). PHP often does not even need build system as we rarely use transpiling to older/newer versions because we don't have this problem of supporting different browsers. Package/file count does not have any meaningful impact of application speed

In general it’s called “dead code elimination.” [1] It’s been around for a long time. A linker can do a basic version of this, but advanced optimizations require whole-program optimization and it’s not typically done since it affects compile time and binary size isn’t as important as it is for web browsers.

GWT was doing tree shaking for Java to JavaScript compilation before most JavaScript programmers had the tool chain for it.

[1] https://en.m.wikipedia.org/wiki/Dead_code_elimination

Here’s a conversation about tree shaking in Lisp from 1994 [1] (from the posted Wikipedia page).

[1] https://groups.google.com/g/comp.lang.lisp/c/pspFr1XByZk

One of the earliest "tree shaker" might be the "selective linker" of MacScheme (an early Scheme implementation for the Apple Macintosh), which was developed in 1985 by William Clinger. It's for example mentioned in the 1987 release announcement for MacScheme+Toolsmith Version 1.0:

https://ml.cddddr.org/scheme/msg00189.html

Lucid Common Lisp had a tree shaker as part of their delivery tool. That one was developed from 1988 onwards.

JS doesn’t really peak in anything. Everything in JS people think is unique has been done decades ago. The comments show that tree shaking is no exception.

Linking?

Reply on news.ycombinator.com