Look at my faster solution without explicit sort. )))

The overall time complexity of this solution is O(N!⋅NlogN).

Brute force should've been stated in the description of the code, but it does encourage people to write more efficent code.

I initally decided to generate all of the permutations and then give back the next biggest one but tests stopped me from doing that.

Not the most efficent one but probably the cleanest.
Although some comments would've helped

Not smart, but, hey-y, it works.

n = 199999

approximate number of operations 720000

I tried this solution trying to solve a similar kata ("Next smaller number with the same digits") and timed out

I went with a more tiny solution but I'mnot fully happy with it. It seems that this Kata wasn't very easy to anyone

Please see my solution to the problem. I think it works for such large numbers.

somehow brute force but nice solution

For anyone who has a problem with this solution, you should blame the test cases, not the solution.

If the author wanted to rule out brute force solutions, they could have included larger numbers for the test cases.

Run it with 19999999 and crack some eggs on your macbook because this baby's gonna get pretty hot!

(actually skip one 9 as this one takes ca. 70sec on my machine)

Seems like the perfomance impact is exponential for cases like this (someone correct me if I'm wrong here).

Cool but slower, but doesn't matter that much when you are solving only this particular problem, but when you need efficiency, it's not good.

Nicely done here, I think it's the most easy-to-understand iterative solution.

Definitely not best practice if it has to test every n + 1 with each following number incremented by 1.