Yes, and AFAIK, you're pretty much free to cause side-effects in functional languages; it's just a bit awkward and somewhat discouraged. It's kind of like how C still has goto, yet it's still a structured programming language.

Even in Haskell, which tries to control side-effects more, it's not hard; it's just that it's stuck with an "IO" annotation. Any function that calls an IO function also becomes an IO function; it's infectious.

  main :: IO ()
  main = putStrLn "hello, world"

There's some real confusion about what "functional" means, because it depends on who's speaking. Writing _exclusively_ pure functions is a Haskell thing. A much looser definition of the functional style would be to say that you mostly write pure functions over immutable data, but when you have to actually do a side effect you write a procedure that talks to the outside world and go on with your day. If you go digging in this site's archives from about ten years ago, I recall numerous debates about what constituted functional programming, and whether the latter counts at all. But if we _are_ talking about Haskell, the answer to your question is obviously "Monads."

The string "Hello World" evaluates to itself, what else do you need?

Edit: Eh, I thought it was a fun quip.

I laughed

Never forget PHP's "Hello World":

    Hello, world!

It has an effect. Whether it's a "side effect" depends on how we've defined that.

One way of viewing Haskell is that you are lazily constructing the single composite "effect on the world" called main.

    helloWorld :: IO ()

then is a value representing an effect, but it only actually happens when it becomes a part of main.

Threads complicate this but don't completely destroy the model.