ls/gnu bloat what?

As an enterprise programmer for the last ten years, being occupied writing services in high level languages with infrastructure grade availability, I was shocked by the sort of "lack of regard" to anything in the ANSI C and Posix API's. I was faced with a system where everything supposedly is a file but its primary programming language has no concept of a file system, where OS specific interfaces to the FS where ridiculously unmaintained as if it had come straight from the stone age...Then, referencing man pages just left a bad taste in my mouth because I found multiple errors (one even wrote that "some systems does not have this", where "some systems" would be my system containing the man page)! I guess it's easier to loose face than fixing a man page by adding relevant documentation, or better yet, fixing the interfaces. This was making me doubting the whole endeavor. Nevertheless, after two days of agony I had an 'ls' clone (equalivent in usage to the ls from coreutils 8.13 with the same optimization as my version).

Now, I decided to have a test and what I found was that my implementation was in average 63% quicker. I can not understand that because my implementation is huge and far from a quick hack, internally it has multiple modes of API's to access the directory structure, it has single linked lists, fixed arrays, a data reader with positioning, multiple sorting algorithms and frickin AA-tree just for fun. Yet, at it's slowest moment it still out-performs GNU ls.

I really can't explain that, what on earth is the coreutils team doing, what are the secrets of ls, how did they make it so slow?

enterprise software is moving to internet software, and internet software is powered largely by gnu + linux. Even oracle has changed their strategy to catch up with salesforce, google, amazon, workday and box. The world has changed and you java drones are going to get left behind.