Currying vs partial application

Both turn a general function into a more specific one by supplying arguments early. The difference is how many arguments at a time and what you get back.

Currying converts f(a, b, c) into f(a)(b)(c). Every call takes exactly one argument and returns another single-argument function, until the last one produces the result. The arity is fixed by the transformation.

Partial application fixes any number of arguments in one go and returns a function that takes all the rest at once. f(a, b, c) with a supplied becomes g(b, c).

const add = (a, b, c) => a + b + c;

// currying — one at a time, always
const curried = (a) => (b) => (c) => a + b + c;
curried(1)(2)(3);            // 6

// partial application — two now, the rest later
const partial = add.bind(null, 1, 2);
partial(3);                  // 6

Why the confusion

Currying enables partial application — calling a curried function with fewer arguments than it needs leaves you holding a partially applied function. And most library curry helpers accept several arguments at once (curried(1, 2)(3)), which blurs the line further. Strictly speaking that is a curried function offering partial application, not currying itself.

Which to reach for

Partial application, almost always. It is built into the language through bind, needs no helper, and reads plainly — log.bind(null, "ERROR") explains itself. Currying is worth the extra machinery when you are composing pipelines of single-argument functions, which is the style Ramda and similar libraries are built around.