The result is that you can easily model a procedure as a series of discreet steps and abstract away clutter. Mutated state and implicit arguments (this) are also typically not used in FP (except where required by the language or for performance reasons)
Upsides to this is that code is explicit, terse, and doesn't get bogged down in the specifics of how the hardware might need to assign pointers to values, etc.
The downside to this is that some people find the mounting abstractions and endless new terms difficult to parse, since FP spends very little time working with primitive values, and since it often is so different from traditional OO languages.
Javascript in particular can be very terse because there's very little boilerplate necessary due to the type system, and because it places no restriction on side-effects, allowing very easy methods of getting things done (but also creating a lot of brittle, bug-prone behaviour)
Haskell and purescript have much more verbosity devoted to types and type manipulation, but produce much more stable/predictable behaviours.
And it depends on what language you are using regularly and what functional language you would like to use.
E.g. If you normally write Java, then FP will almost always be more terse. I am learning Clojure and it’s a lot less code than Java, and it can even natively call Java code as it runs on the JVM
It takes so much effort to satisfactorily define a type, or a function, in earlier versions of these languages. They've improved, though.
It can be more terse but that doesn't make less code overall.