Where did you get this idea? Depending on your task, Erlang can be very fast with IO because it will aggressively use writev/readv instead of write. Obviously, you can do this if you "know about it" in low level langs, but it might be a pain.
Erlang is generally considered to be compute-slow (which is generally the case without dropping to nifs).
Is IO in Erlang slow? I never got that impression; iolists are a good fit for scatter/gather I/O, which reduces copying, and Erlang supports kqueue, epoll, and I believe similar on Windows. I don't follow Erlang on Linux closely, so I don't know if there's any movement towards io_uring, which does seem promising to help with throughput.
Either way, I wouldn't expect doing I/O in NIFs or ports to substantially improve throughput, unless you're also moving significant processing into that layer as well, or you're going to end up doing substantially the same level of marshaling work as ERTS does, just in a different language. Setting up a different set of kqueue/epoll descriptors sounds like a lot of work for not much gain too, IMHO; again, maybe io_uring would be useful, but I think you'd be better served to bite the bullet and integrate it with ERTS.
IO in Erlang is faster than many other managed languages, thanks to stuff like IO Lists that are dealt with very efficiently through iovec syscalls (readv, writev).
Then add efficient pattern matching for binary data, and networked servers on the BEAM are the most ergonomic than any other language.
All this stuff that the BEAM offers you out of the box can be replicated in any native language with a lot of boilerplate and ceremony.
Your "Hello, <name>" webapp in Rust will probably need two allocations and a string concatenation, while on the BEAM, if constructed as an iolist, it's a single writev syscall, using a static "Hello, " string and a shared "<name>" reference from the parsed HTTP data.
Erlang is generally considered to be compute-slow (which is generally the case without dropping to nifs).