Reading up till here, you're probably thinking that all operations we performed in that program is possible with Collections itself in Kotlin, so why should we use Streams? To answer that, we should first learn the differences between Streams and Collections. So, let's have a look at the following list consisting of differences between Collections and Streams:

• As the definition of Collections says, a Collection is a data structure which stores and lets you work with a group of data. Streams, on the other hand, aren't data structures and don't store anything; they work like a pipeline or IO channel, which fetches data from its source on demand.
• Every data structure must have a finite size limit, and the same applies to Collections as well. But, as Streams are not data structures, they don't need to have any specific size limit.
• While accessing elements of a Collection directly, you can do it any time, even for the same position, without the requirement of recreating the Collection. But when working with Streams, elements of a Stream are only visited once during the life of a Stream. Like an iterator, a new Stream must be generated to revisit the same elements of the source.
• The Collection API constructs objects in an eager manner, always ready to be consumed. The Stream API creates objects in a lazy, on-demand basis.
• The Collection API is used for storing data in different kinds of data structures. The Stream API is used for the computation of data on a large set of objects.

So, these were very basic differences between the Collection API and the Stream API. At a glance, the Streams seem like RxKotlin, Observables which provide a way to consume the data, but there are a lot of significant differences between Streams and Observables. These are the differences between Streams and Observables:

• The first notable difference is that Streams are pull-based, and Observables are push-based. This may sound too abstract, but it has significant consequences that are very concrete.
• With Observables, it's easy to change threads or specify thread pools for a chain with ease, thanks to Schedulers. But, with Streams, it's a bit tricky.
• Observables are synchronized all the way through. This spares you from checking all the time whether these basic operations are thread safe.
• One more significant difference is that Observables have a lot more functional interfaces than the Streams API, which makes Observables easy to use with a lot of options to accomplish a certain task.

So, we learned that Streams are not a data structure but are like an abstract layer on top of the data source (which may be Collections or anything else), and even though Streams construct objects in a lazy, on-demand basis, they are still pull-based and use loops inside them.